>Number:         26822
>Category:       kern
>Synopsis:       uvmexp.anonpages account incorrect
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 01 11:58:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        NetBSD 2.0_BETA from May 22 2004 sources.
>Organization:
Wasabi Systems
>Environment:
System: NetBSD thoreau.thistledown.com.au 2.0_BETA NetBSD 2.0_BETA
    (THOREAU) #1: Sat May 22 22:59:18 EST 2004
    simonb@thoreau:/usr/obj/sys/arch/i386/compile/THOREAU i386
Architecture: i386
Machine: i386

>Description:
        uvmexp.anonpages can become incorrect.  As an example, my 2.0
        BETA box that has been up for 98 days currently says:

        $ vmstat -s | egrep 'managed|anonymous|cached' | grep -v scanned
           127992 pages managed
           490879 anonymous pages
            14622 cached file pages
            12453 cached executable pages

        A little program that walks the kernel page lists says that
        there are 48595 anon pages and 27179 pages attached to objects.
        The sum of file and exec pages is close to the pages backed by
        objects from the above vmstat output.

	At least one other 2.0 branch box shows the following values:

           902343 pages managed
          4416488 anonymous pages
           645743 cached file pages
             3657 cached executable pages

        Obviously there can not be more anon pages than total pages.
        The vmstat numbers match gdb run on the live kernel and querying
        uvmexp directly, so it's not some silly reporting bug in vmstat.

        At least for the current sysctl vm.*min/max knobs on this box
        the page daemon will think that both anon and file pages are
        available for reclaim when in fact it should only be reclaiming
        file backed pages in low memory situations.

        uvmexp.anonpages is only changed in a handful of places in
        uvm/uvm_page.c and they all look right at a glance.  However,
        there must be some accounting problem lurking there somewhere.


>How-To-Repeat:
        Keep a box up long enough so that the anonpages accounting gets
        confused?

>Fix:
        None given...
>Release-Note:
>Audit-Trail:
>Unformatted: