* eeh@netbsd.org <eeh@netbsd.org> [020408 12:42] wrote:
> 
> So. getting back to the original point, if you really are locking up
> due to lack of pages, there is nothing that can be done because you 
> simply need more memory than you have on that machin.  However, if
> you want to handle that situation gracefully, you need to track and
> limit overcommit.

There's actually a couple of things one can do:

1) instead of _randomly_ killing a process, you pick one based on
   certain tuneable parameters (or a combination of them) such as:
   a) process owner (don't kill root processes)
   b) youngest process (kill netscape but not the X server)
   c) process who's made the most memory demands most recently
      this can be accomplished by tracking how many pages are
      actually _used_ in a certain time period per process, the
      one that's the most demanding gets the axe.
   d) allow processes to mark themselves more or less preferential
      to being shot down.
2) implement something like AIX's 'SIGDANGER', to inform processes
   when memory is low, processes with a handler installed will then
   try to reclaim resources and probably be on the low list for being
   shot down when the actual shortage does occur.

A combination of both these ideas would make for a much more robust
system with flexbility.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/