lkml.org 
[lkml]   [2001]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: page_launder() on 2.4.9/10 issue
From
On Tue, Sep 04, 2001 at 07:49:47PM +0100, Alan Cox wrote:
> The VM tuning in the -ac tree is a lot more reliable for most loads (its
> certainly not perfect) and that is because the changes have been done and
> tested one at a time as they are merged. Real engineering process is the
> only way to get this sort of thing working well.

I grabbed the 2.4.9-ac7 patch and looked at some of the files.

Pages allocated with do_anonymous_page are not added to the active list.
as a result there is no aging information for a page until it is
unmapped. So we might be unmapping and allocating swap for shared pages
that another process is using heavily. In which case this page should
always have a high age in in the active list and won't actually get
swapped out. So we get both unnecessary minor faults, and the swap space
will never be reclaimed because we never swap it back in.

Also up aging of mapped process pages is still done in try_to_swap_out,
and all of these pages are still aged down indiscriminately in
refill_inactive_scan. I don't see how it could age that much
differently, so I'm assuming all pages in the active list are basically
at age 0 no matter what aging strategy is picked.

Especially because only down aging is performed periodically by kswapd,
while the only code that ages process pages up is only called once the
system hits free or inactive shortage.

There is some places where tests have been added that should never make
a difference anyways. In reclaim_page and page_launder a page on the
inactive list is checked for page->age. Because the page is not mapped
in any VM it is not possibly for age to be non-zero. If the page was
referenced it would have triggered a minor fault and reactivated the
page.

I guess it is just more carefully papering over the existing problems.

Jan

-
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: 2005-03-22 13:02    [W:0.089 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site