Date: Thu, 12 Jun 2003 04:58:12 +0200
From: Andrea Arcangeli <andrea@suse.de>
To: Nick Piggin <piggin@cyberone.com.au>
Cc: Chris Mason <mason@suse.com>,
       Marc-Christian Petersen <m.c.p@wolk-project.de>,
       Jens Axboe <axboe@suse.de>, Marcelo Tosatti <marcelo@conectiva.com.br>,
       Georg Nikodym <georgn@somanetworks.com>,
       lkml <linux-kernel@vger.kernel.org>,
       Matthias Mueller <matthias.mueller@rz.uni-karlsruhe.de>
Subject: Re: [PATCH] io stalls
Message-ID: <20030612025812.GF1415@dualathlon.random>
References: <1055353360.23697.235.camel@tiny.suse.com> <20030611181217.GX26270@dualathlon.random> <1055356032.24111.240.camel@tiny.suse.com> <20030611183503.GY26270@dualathlon.random> <3EE7D1AA.30701@cyberone.com.au> <20030612012951.GG1500@dualathlon.random> <1055384547.24111.322.camel@tiny.suse.com> <3EE7E876.80808@cyberone.com.au> <20030612024608.GE1415@dualathlon.random> <3EE7EA4A.5030105@cyberone.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EE7EA4A.5030105@cyberone.com.au>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2691
Lines: 70

On Thu, Jun 12, 2003 at 12:49:46PM +1000, Nick Piggin wrote:
> 
> 
> Andrea Arcangeli wrote:
> 
> >On Thu, Jun 12, 2003 at 12:41:58PM +1000, Nick Piggin wrote:
> >
> >>
> >>Chris Mason wrote:
> >>
> >>
> >>>On Wed, 2003-06-11 at 21:29, Andrea Arcangeli wrote:
> >>>
> >>>
> >>>
> >>>>this will avoid get_request_wait_wakeup to mess the wakeup, so we can
> >>>>wakep_nr(rq.count) safely.
> >>>>
> >>>>then there's the last issue raised by Chris, that is if we get request
> >>>>released faster than the tasks can run, still we can generate a not
> >>>>perfect fairness. My solution to that is to change wake_up to have a
> >>>>nr_exclusive not obeying to the try_to_wakeup retval. that should
> >>>>guarantee exact FIFO then, but it's a minor issue because the requests
> >>>>shouldn't be released systematically in a flood. So I'm leaving it
> >>>>opened for now, the others already addressed should be the major ones.
> >>>>
> >>>>
> >>>I think the only time we really need to wakeup more than one waiter is
> >>>when we hit the q->batch_request mark.  After that, each new request
> >>>that is freed can be matched with a single waiter, and we know that any
> >>>previously finished requests have probably already been matched to their
> >>>own waiter.
> >>>
> >>>
> >>>
> >>Nope. Not even then. Each retiring request should submit
> >>a wake up, and the process will submit another request.
> >>So the number of requests will be held at the batch_request
> >>mark until no more waiters.
> >>
> >>Now that begs the question, why have batch_requests anymore?
> >>It no longer does anything.
> >>
> >
> >it does nothing w/ _exclusive and w/o the wake_up_nr, that's why I added
> >the wake_up_nr.
> >
> >
> That is pretty pointless as well. You might as well just start
> waking up at the queue full limit, and wake one at a time.
> 
> The purpose for batch_requests was I think for devices with a
> very small request size, to reduce context switches.

batch_requests at least in my tree matters only when each request is
512btyes and you've some thousand of them to compose a 4M queue or so.
To maximize cpu cache usage etc.. I try to wakeup a task every 512bytes
written, but every 32*512bytes written or so. Of course w/o the
wake_up_nr that I added, that wasn't really working w/ the _exlusive
wakeup.

if you check my tree you'll see that for sequential I/O with 512k in
each request (not 512bytes!) batch_requests is already a noop.

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/