Re: Random file I/O regressions in 2.6

[Andrew Morton]

Peter Zaitsev <peter@xxxxxxxxx> wrote:
>
> On Mon, 2004-05-03 at 13:57, Andrew Morton wrote:
> > Ram Pai <linuxram@xxxxxxxxxx> wrote:
> > >
> > > > The place which needs attention is handle_ra_miss().  But first I'd like to
> > > > reacquaint myself with the intent behind the lazy-readahead patch.  Was
> > > > never happy with the complexity and special-cases which that introduced.
> > > 
> > > lazy-readahead has no role to play here.
> > 
> 
> Andrew,
> 
> Could you please clarify how this things become to be dependent on
> read-ahead at all.

readahead is currently the only means by which we build up nice large
multi-page BIOs.

> At my understanding read-ahead it to catch sequential (or other) access
> pattern and do some advance reading, so instead of 16K request we do
> 128K request, or something similar.

That's one of its usage patterns.  It's also supposed to detect the
fixed-sized-reads-seeking-all-over-the-place situation.  In which case it's
supposed to submit correctly-sized multi-page BIOs.  But it's not working
right for this workload.

A naive solution would be to add special-case code which always does the
fixed-size readahead after a seek.  Basically that's

	if (ra->next_size == -1UL)
		force_page_cache_readahead(...)

in filemap.c.  But this means that the kernel does lots of pointless
pagecache lookups when everything is in pagecache.  We should detect this
situation and stop doing readahead completely, until we start getting
pagecache lookup misses again.

> But how could read-ahead disabled end up in 16K request converted to
> several sequential synchronous 4K requests ? 

Readahead got itself turned off because of pagecache hits and didn't turn
itself on again.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/