That part of the code doesn't.
> Effectively this is just a 'binary' aging function (OK position
> on the list matters too). Others on the list have observed
> page->age performs in a binary manner anyhow with exponential
> aging.
Right. I'm not saying that this is anything _exiting_ - I'm just saying
that the old code did not have any clear behaviour at all. It would
inappropriately raise a page from the inactive lists to the active list
even if the code that actually _touched_ the page had decided that the
page was not active.
And the behaviour of the referenced bit once on the active list was
unclear. I personally think that clearing the reference bit when moving to
the active list is the right thing to do (so that it is marked
"unimportant" on the active list and needs a _third_ access to be marked
important), but this is an example of one of the tweaks/decisions we
should clearly make instead of leaving the behaviour undefined (which it
was before).
> How do you balance between Inactive Clean before Inactive Dirty
> and avoid evicting many (infrequently used) code pages at
> the expense of many (historic, even less frequently used) dirty
> data pages? Or don't we care?
We probably _do_ care. I suspect that if there are balancing problems,
they could easily be in the reclaim_page() vs page_launder() balance (ie
aging of inactive_clean vs inactive_dirty).
Linus
-
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/