"Erik E. Fair" writes:
> As for the swap question, it really devolves down to the resource
> accounting issue, which you get into whether you have swap or not: how well
> does NetBSD deal when there is no more RAM (or RAM+swap)?
> 
> I know that the MACH VM had this notion of "lazy allocation" which allowed
> for large, sparse address spaces, but lost terribly if a resource crunch
> hit. I also know that we've been tightening up on the resource accounting
> with UVM, but it's not clear to me what we do for the "sorry, we're all
> out" case right now.
> 
> I'm all in favor of the suggestion that was made the last time this came
> up: a VM with two behavior modes: strict accounting, and lazy accounting,
> where the strict model doesn't allow anyone to allocate more RAM than you
> have, and the lazy model allows you to ask for whatever you want, just so
> long as you don't use it all. This sort of thing probably has to be a
> system-wide policy decision, though there was a suggestion that it could be
> per-process, provided that a process which requested lazy allocation would
> be the first to die in a crunch.

Mach VM would invariably hang if something allocated all the RAM+swap
in the system and still wanted more.  UVM in 1.4 deals with this by
killing anyone who wants to allocate another swap-backed page when
RAM+swap is full, on the theory that the process that allocates the
next page is the one most likely to be causing the shortage.

as for eager vs. lazy swap allocation, I agree that making it globally
selectable is a good plan.  we should probably have the system come up
in eager mode, with a one-way sysctl to switch to lazy mode.  this is
not very near the top of my todo list (or chuck c's either, I think),
so it'll be a long time in coming unless someone else steps up to do the
work.  hint, hint :-)

-Chuck