Re: broken VM in 2.4.10-pre9

[Daniel Phillips]

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

--
Daniel