Subject: Re: NetBSD1.6 UVM problem?
To: Sylvain Fontaine <sfontaine@hyperchip.com>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 12/08/2002 11:02:54
hi,

yes, the heuristic for determining when to start killing processes
when no swap is available doesn't work so well when there's no swap
configured.  in this case, it would be useful to count RAM that isn't
reserved for other usage types as potentially available for swap-backed
allocation.   all the places in uvm_fault() that return ENOMEM currently
use "uvmexp.swpgonly == uvmexp.swpages" as the indicator that sleeping
won't free up any more memory that could be used for anons, but when
there's no swap then both sides of that comparison are always zero.

we could replace that with something more like

	int t;

	t = uvmexp.active + uvmexp.inactive + uvmexp.free;
	if (uvmexp.swpgonly == uvmexp.swpages &&
            uvmexp.filepages <= ((t * uvmexp.filemin) >> 8) &&
	    uvmexp.execpages <= ((t * uvmexp.execmin) >> 8)) {
		return ENOMEM;
	}

(and yea, I should make some macros for doing the fixed-point math.)
this means that we will only start killing processes when swap is full
and the file and exec pages have been reduced to their minimum levels.

does that do anything useful for you?

-Chuck


On Fri, Dec 06, 2002 at 11:35:13AM -0500, Sylvain Fontaine wrote:
> 
> I found a behavior with the UVM that seems to be wrong.
> My system has no swap space. 1G of RAM.
> 
> Here's what I see:
> - Create a file of 100M on a MFS of 100M.  Then 200M are removed from free,
> 100M active, 100M file.
>   I'm left with about 730M of free mem now, but with 100M file memory
> available when needed.
> - I start a program that calloc (not malloc) 800M.  I expect file memory to
> be returned to me.
>   The test program does callocation by 100M slices.
> - The page deamon does not react until its free_target is not under.  About
> ~~500k.
> - When the page deamon finds the free_target not to be met, it starts
> recovering pages, 
>   but there's a race condition freeing/allocating and my test app wins...
> resulting in faulting
>   and being killed by the UVM when uvm_fault returns ENOMEM.  
> 
> 
> I found two solutions:
> 1) In this condition, when I know there is still memory I can retrieve from
> file memory,
>     I call uvm_wait, and tell the pagedeamon to overlook the free_target and
> to free 
>     some pages because I need some, even if the free_target is met.
> 2) Increraese the free target to 1/20 of my memory ~50M... This way the race
> begins sooner
>     And the pagedeamon wins.
> 
> Sylvain