Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S264790AbTBJJEn>; Mon, 10 Feb 2003 04:04:43 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S264799AbTBJJEn>; Mon, 10 Feb 2003 04:04:43 -0500
Received: from [195.223.140.107] ([195.223.140.107]:59777 "EHLO athlon.random")
	by vger.kernel.org with ESMTP id <S264790AbTBJJEm>;
	Mon, 10 Feb 2003 04:04:42 -0500
Date: Mon, 10 Feb 2003 10:14:13 +0100
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@digeo.com>
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: <20030210091413.GQ31401@dualathlon.random>
References: <Pine.LNX.4.44.0302092018180.15944-100000@dlang.diginsite.com> <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> <20030210085649.GO31401@dualathlon.random> <20030210010937.57607249.akpm@digeo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030210010937.57607249.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: 1501
Lines: 34

On Mon, Feb 10, 2003 at 01:09:37AM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > On Mon, Feb 10, 2003 at 12:19:21AM -0800, Andrew Morton wrote:
> > > Andrea Arcangeli <andrea@suse.de> 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.
> > 
> 
> No, it's doing the directory readahead against the correct blocks (it calls
> ext3_getblk() to find them).

yes, sorry.

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/