Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263503AbTFKSVl (ORCPT ); Wed, 11 Jun 2003 14:21:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263542AbTFKSVl (ORCPT ); Wed, 11 Jun 2003 14:21:41 -0400 Received: from ppp-217-133-42-200.cust-adsl.tiscali.it ([217.133.42.200]:2258 "EHLO dualathlon.random") by vger.kernel.org with ESMTP id S263503AbTFKSVj (ORCPT ); Wed, 11 Jun 2003 14:21:39 -0400 Date: Wed, 11 Jun 2003 20:35:03 +0200 From: Andrea Arcangeli To: Chris Mason Cc: Nick Piggin , Marc-Christian Petersen , Jens Axboe , Marcelo Tosatti , Georg Nikodym , lkml , Matthias Mueller Subject: Re: [PATCH] io stalls (was: -rc7 Re: Linux 2.4.21-rc6) Message-ID: <20030611183503.GY26270@dualathlon.random> References: <3EDDDEBB.4080209@cyberone.com.au> <1055194762.23130.370.camel@tiny.suse.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1055356032.24111.240.camel@tiny.suse.com> User-Agent: Mutt/1.4i X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1569 Lines: 39 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/