According to woods@most.weird.com:
> 
> > I didn't specify, but my scheme needs to be some mechanism for firing
> > off a process, or waking up an existing process when swap reaches the
> > high water mark.
> 
> Regardless of how agressively the system tries to recover from a VM
> over-commit situation, there should still be a high-water mark that can
> be set far enough below the physical limit to allow the superuser to
> have a wee bit of room to work with *IF* indeed there's a superuser
> handy to do such things....
> 
> (And no, there shouldn't be any way to assign the space above the limit
> to some other user-id or group-id.  This is unix, with one, and only
> one, superuser ID; not multics.)
> 
You raise an interesting point, here: what happens if the root process 
then setuid()s to a less privileged user?

++L