Re: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]

From: Andrew Morton <akpm@digeo.com>
To: Andrea Arcangeli <andrea@suse.de>
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]
Date: Mon, 10 Feb 2003 01:09:37 -0800	[thread overview]
Message-ID: <20030210010937.57607249.akpm@digeo.com> (raw)
In-Reply-To: <20030210085649.GO31401@dualathlon.random>

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).

Large directories tend to be spread all around the disk anyway.  And I've
never explicitly tested for any problems which the loss of readahead might
have caused ext2.  Nor have I tested inode table readahead.  Guess I should.