Messages in this thread |  | | | Date | Mon, 3 May 2004 14:59:22 -0700 | | From | Andrew Morton <> | | Subject | Re: Random file I/O regressions in 2.6 |
| |
Peter Zaitsev <peter@mysql.com> wrote: > > On Mon, 2004-05-03 at 13:57, Andrew Morton wrote: > > Ram Pai <linuxram@us.ibm.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |