lkml.org 
[lkml]   [2003]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]
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.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.093 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site