lkml.org 
[lkml]   [2003]   [Feb]   [10]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateMon, 10 Feb 2003 10:14:13 +0100
FromAndrea Arcangeli <>
SubjectRe: stochastic fair queueing in the elevator [Re: [BENCHMARK] 2.4.20-ck3 / aa / rmap with contest]
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/

\
 
 \ /
  Last update: 2005-03-22 12:33    [W:0.597 / U:0.110 seconds]
©2003-2008 Jasper Spaans