Message-ID: <3EE7E876.80808@cyberone.com.au>
Date: Thu, 12 Jun 2003 12:41:58 +1000
From: Nick Piggin <piggin@cyberone.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4
MIME-Version: 1.0
To: Chris Mason <mason@suse.com>
CC: Andrea Arcangeli <andrea@suse.de>,
       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
References: <20030611003356.GN26270@dualathlon.random>	 <1055292839.24111.180.camel@tiny.suse.com>	 <20030611010628.GO26270@dualathlon.random>	 <1055296630.23697.195.camel@tiny.suse.com>	 <20030611021030.GQ26270@dualathlon.random>	 <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>
In-Reply-To: <1055384547.24111.322.camel@tiny.suse.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1528
Lines: 39


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.

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