Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Feb 2003 03:47:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Feb 2003 03:47:29 -0500 Received: from [195.223.140.107] ([195.223.140.107]:54657 "EHLO athlon.random") by vger.kernel.org with ESMTP id ; Mon, 10 Feb 2003 03:47:28 -0500 Date: Mon, 10 Feb 2003 09:56:49 +0100 From: Andrea Arcangeli To: Andrew Morton Cc: piggin@cyberone.com.au, jakob@unthought.net, david.lang@digitalinsight.com, riel@conectiva.com.br, ckolivas@yahoo.com.au, linux-kernel@vger.kernel.org, axboe@suse.de Subject: Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest] Message-ID: <20030210085649.GO31401@dualathlon.random> References:

<20030209203343.06608eb3.akpm@digeo.com> <20030210045107.GD1109@unthought.net> <3E473172.3060407@cyberone.com.au> <20030210073614.GJ31401@dualathlon.random> <3E47579A.4000700@cyberone.com.au> <20030210080858.GM31401@dualathlon.random> <20030210001921.3a0a5247.akpm@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030210001921.3a0a5247.akpm@digeo.com> User-Agent: Mutt/1.4i X-GPG-Key: 1024D/68B9CB43 X-PGP-Key: 1024R/CB4660B9 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1189 Lines: 25 On Mon, Feb 10, 2003 at 12:19:21AM -0800, Andrew Morton wrote: > Andrea Arcangeli wrote: > > > > BTW, one thing that should definitely do readhaead and it's > > not doing that (at least in 2.4) is the readdir path, again to generate > > big commands, no matter the seeks. It was lost with the directory in > > pagecache. > > Yes. But ext3 is still doing directory readahead, and I have never > noticed it gaining any particular benefit over ext2 from it. At least for big directories it should be at least a quite obvious microoptimization, if you do it at the logical level. Maybe it wasn't worthwhile in the past (like in ext3) because it was done at the block layer with a dumb reada rather than with proper read of the next logical block before wait_on_buffer. Also keep in mind the max readahead generated by the block layer is nothing compared to the true readahead that the logical layer is able to generate. 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/