On Sat, Aug 14, 2004 at 08:19:46AM +0200, Havard Eidnes wrote:
   > > If this guesswork is right, I don't really have any idea how to go about
   > > fixing it, though -- that would be something for the VM experts among us.
   > 
   > Intuitively it would seem that some memory should be reserved for
   > e.g. the pool allocator and that backpressure on the other users of
   > physical memory needs to imposed a bit earler than before we run
   > completely out.
   
   Would it help to remove these lines from uvm_pdaemon.c::uvmpd_tune() ?
   
   	uvmexp.freemin = uvmexp.npages / 20;
   
   ->	/* between 16k and 256k */
   ->	/* XXX:  what are these values good for? */
   ->	uvmexp.freemin = MAX(uvmexp.freemin, (16*1024) >> PAGE_SHIFT);
   ->	uvmexp.freemin = MIN(uvmexp.freemin, (256*1024) >> PAGE_SHIFT);
   
   The min threshhold (16*1024) will almost never be used as it means a
   memory size of 20*2*8k == 320k for a pagesize of 8k. So it will always
   clamp uvmexp.freemin to 256k which is very low for modern memory sizes.


these values actually come from 4.4BSD/machvm completely untouched.

many many years ago i spent some time trying to determine better values
for this but i didn't really discover anything conclusive...


however, this shouldn't really affect the pool allocator... we already
reserve a bunch of pages for such conditions i thought.


.mrg.