[lkml]   [2001]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: broken VM in 2.4.10-pre9
> That still doesn't mean we can't _approximate_ aging in
> another way. With linear page aging (3 up, 1 down) the
> page ages of pages referenced only in the page tables
> will still go up, albeit a tad slower than expected.
> It's exponential aging which makes the page age go into
> the other direction, with linear aging things seem to
> work again.
> I've done some experiments recently and found that (with
> reverse mappings) exponential aging is faster when we have
> a small inactive list and linear aging is faster when we
> have a large inactive list.

Have you tried making the down increment larger and the up increment smaller
when the active list is larger? This has a natural interpretation: when the
active list is large the scanning period is longer. During this longer scan
period an active page *should* be more likely to have its ref bit set, so it
gets a smaller boost if it is. If not we should penalize it more heavily.

There are three points here:

- small inactive list really means large active list (and vice versa)
- aging increments need to depend on the size of the active list
- "exponential" aging may be completely bogus

> This means we need linear page aging with a large inactive
> list in order to let the page ages move into the right
> direction when we run a system without reverse mapping,
> the patch for that was sent to Alan yesterday.

So, the question is, does my suggestion produce essentially the same
beneficial effect? And by the way, what are your test cases? I'd like to
see if I can your results here.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.054 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site