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


Andrea Arcangeli wrote:

>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.
>

And go to the end of the queue?

>
>>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, this isn't needed because when the queue falls below
the batch limit, every retiring request will do a wake up and
another request will be put on (as long as the waitqueue is
active).


-
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    [W:0.458 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site