Garance A Drosihn wrote:
> 
> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote:
> > In which case the program that consumed all memory will be killed.
> > The program killed is +NOT+ the one demanding memory, it's the one
> > with most of it.
> 
> But that isn't always the best process to have killed off...
> 
> One of my main freebsd machines is mainly here to run one
> process, which is a pretty good-sized process (>40meg).  If
> I did get into a memory-shortage problem, I do *not* want
> that process killed, I'd want some other processes killed.
> 
> It would be nice to have a way to indicate that, a la SIGDANGER.

Another option may be to add something like "importance classes".
Suppose we assign an one-byte "importance level" to each process.
When we get out of swap we start killing processes with the lowest
importance level. This seems to be both easy to implement and
a rather robust solution.

It can be extended to more flexible policies: say, we divide
this 8-bit number into two 4-bit fields. The high field
will be "major importance level" the low field will be "importance
sublevel". We permit the user processes to change their
sublevel to any value as long their major level stays the same
or becomes lower. This will allow the users to make differences
between their programs but only in certain limits. The initial
importance level may be set in /etc/login.conf.

One more extension would be to use one bit as the ihneritance
flag: if it is set, the child inherits the importance value
from the parent. But if it's reset the child inherits its
major level from the parent but the sublevel gets reset to 0.
It may be useful for transparent calls of system().
Yet another extension would be to use two separate inheritance
bits: one as described above, the secone one if reset means that 
the importance value of the child must be reset to the lowest one.

-SB