On Fri, Dec 18, 1998 at 11:49:24AM +1030, Ian Dall wrote:
> My high water mark idea has some advantages. No one has to be killed
> for anything, they are just put to sleep while root processes, which
> are allowed to use the reserve swap, fix the problem. It puts policy
> decisions like who to kill first (if anyone) in user land and not in
> the kernel (which seems good to me). There are no code change needed to
> trap new signals. Finally, there is precedent in the FFS
> implementation. It provides better protection against DoS than simply
> preventing overcommit.

This sounds simple enough to be implemented and tested in a relatively
short time, right?  (I mean the kernel side of things.)  Might be worth
a try?  The high water level should be settable using sysctl, I guess.
(Well, I'd like to be able to allow some other user(s) to allocate swap
in low swap conditions in addition to root.. but this would add some
overhead to the system, I guess.)

> 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.

Firing up a new process (loading code from disk etc) sounds scary in
such a situation (where the system tends to lock up completely at the
moment :-)

  -jm