Messages in this thread | | | Date | Tue, 04 May 2004 09:58:01 +1000 | From | Nick Piggin <> | Subject | Re: Random file I/O regressions in 2.6 |
| |
Andrew Morton wrote: > 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(...) >
I think a better solution to this case would be to ensure the readahead window is always min(size of read, some large number);
The size of the read is basically a free and accurate "hint" to the minimum size of the required readahead.
Either that or do a simple "preread" while you're still in the read request window, and run readahead when that completes. - 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/
| |