lkml.org 
[lkml]   [2006]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 12/33] readahead: min/max sizes
Wu Fengguang wrote:

>- Enlarge VM_MAX_READAHEAD to 1024 if new read-ahead code is compiled in.
> This value is no longer tightly coupled with the thrashing problem,
> therefore constrained by it. The adaptive read-ahead logic merely takes
> it as an upper bound, and will not stick to it under memory pressure.
>

I guess this size enlargement is one of the main reasons your
patchset improves performance in some cases.

There is currently some sort of thrashing protection in there.
Obviously you've found it to be unable to cope with some situations
and introduced a lot of really fancy stuff to fix it. Are these just
academic access patterns, or do you have real test cases that
demonstrate this failure (ie. can we try to incrementally improve
the current logic as well as work towards merging your readahead
rewrite?)

--

Send instant messages to your online friends http://au.messenger.yahoo.com

-
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/

\
 
 \ /
  Last update: 2006-05-25 06:53    [W:0.318 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site