On Sun, Jul 22, 2007 at 10:59:11AM +0200, Peter Zijlstra wrote: > On Sun, 2007-07-22 at 16:45 +0800, Fengguang Wu wrote: > > How about the following rules? > > - limit it under 1MB: we have to consider latencies > > readahead is done async and we have these cond_resched() things > sprinkled all over, no?
Yeah, it should not be a big problem. > > - make them alignment-friendly, i.e. 128K, 256K, 512K, 1M. > > Would that actually matter? but yeah, that seems like a sane suggestion. > roundup_pow_of_two() comes to mind. E.g. RAID stride size, and the max_sectors_kb. Typically they are power-of-two. > > My original plan is to simply do the following: > > > > - #define VM_MAX_READAHEAD 128 /* kbytes */ > > + #define VM_MAX_READAHEAD 512 /* kbytes */ > > Yeah, the trouble I have with that is that it might adversely affect > tiny systems (although the trash detection might mitigate that impact) I'm also OK with the scaling up scheme. It's reasonable. > > I'd like to post some numbers to back-up the discussion: > > > > readahead readahead > > size miss > > 128K 38% > > 512K 45% > > 1024K 49% > > > > The numbers are measured on a fresh booted KDE desktop. > > > > The majority misses come from the larger mmap read-arounds. > > the mmap code never gets into readahead unless madvise(MADV_SEQUENTIAL) > is used afaik. Sadly mmap read-around reuses the same readahead size. - for read-around, VM_MAX_READAHEAD is the _real_ readahead size - for readahead, VM_MAX_READAHEAD is the _max_ readahead size If we simply increasing VM_MAX_READAHEAD, tiny systems can be immediately hurt by large read-arounds. That's the problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
