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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
