[lkml]   [2001]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: page_launder() on 2.4.9/10 issue
    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

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


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