From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264676AbTFLC2n (ORCPT ); Wed, 11 Jun 2003 22:28:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264689AbTFLC2m (ORCPT ); Wed, 11 Jun 2003 22:28:42 -0400 Received: from dyn-ctb-210-9-241-68.webone.com.au ([210.9.241.68]:29188 "EHLO chimp.local.net") by vger.kernel.org with ESMTP id S264676AbTFLC2j (ORCPT ); Wed, 11 Jun 2003 22:28:39 -0400 Message-ID: <3EE7E876.80808@cyberone.com.au> Date: Thu, 12 Jun 2003 12:41:58 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4 X-Accept-Language: en MIME-Version: 1.0 To: Chris Mason CC: Andrea Arcangeli , Marc-Christian Petersen , Jens Axboe , Marcelo Tosatti , Georg Nikodym , lkml , Matthias Mueller 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 X-Mailing-List: linux-kernel@vger.kernel.org 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.