Hi, On Mon, Mar 17, 2008 at 10:41:01AM +0000, Samuel Thibault wrote: > [EMAIL PROTECTED], le Sun 16 Mar 2008 08:52:56 +0100, a écrit :
> > What makes me wonder is, how can it happen in the first place that > > so many requests are generated before the superblock is requested > > during handling of the first one? > > ld-ing xulrunner, which needs a lot of memory (thus paging out > superblock), and then suddenly needs to write a lot of data, which > seemingly is not processed immediately, but on the periodical > sync_all. Well yes, I do understand why many requests are created in short succession. But that is not the question. If there are no other blocking points before the superblock read, the first request should be able to kick off the superblock read before the thread originally creating the requests is scheduled again -- before it can create further requests. Why is that not the case? This is really the main problem here. Even if we change the thread model such that the request storm doesn't result in a deadlock (with thread limiting) or resource exhaustion (without limiting), it will still result in terrible performance. We need to avoid it. I don't know how the syncing works, so I can't really tell what the problem is. If there are blocking points before the superblock read, we need to change that somehow. If the superblock read is the first blocking point already, we need to change the scheduling, to make sure that the request is handled -- up to the first blocking point -- before returning to the requester. -antrik-
