lkml.org 
[lkml]   [2003]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] io stalls (was: -rc7 Re: Linux 2.4.21-rc6)
On Wed, Jun 11, 2003 at 02:27:13PM -0400, Chris Mason wrote:
> On Wed, 2003-06-11 at 14:12, Andrea Arcangeli wrote:
> > On Wed, Jun 11, 2003 at 01:42:41PM -0400, Chris Mason wrote:
> > > + if (q->rq[rw].count >= q->batch_requests) {
> > > + smp_mb();
> > > + if (waitqueue_active(&q->wait_for_requests[rw]))
> > > + wake_up(&q->wait_for_requests[rw]);
> >
> > in my tree I also changed this to:
> >
> > wake_up_nr(&q->wait_for_requests[rw], q->rq[rw].count);
> >
> > otherwise only one waiter will eat the requests, while multiple waiters
> > can eat requests in parallel instead because we freed not just 1 request
> > but many of them.
>
> I tried a few variations of this yesterday and they all led to horrible
> latencies, but I couldn't really explain why. I had a bunch of other

the I/O latency in theory shouldn't change, we're not reordering the
queue at all, they'll go to sleep immediatly again if __get_request
returns null.

> stuff in at the time to try and improve throughput though, so I'll try
> it again.
>
> I think part of the problem is the cascading wakeups from
> get_request_wait_wakeup(). So if we wakeup 32 procs they in turn wakeup
> another 32, etc.

so maybe it's enough to wakeup count / 2 to account for the double
wakeup? that will avoid some overscheduling indeed.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:36    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean