At 2:40 AM +0900 7/15/99, Daniel C. Sobral wrote:
>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...
>
>Sure it is. :-) Let's see...
>
>> 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.
>
> Just size your swap so that it becomes unlikely that you run out of
> memory before a process exceeds 40Mb.
>
> And I mean it.

For the moment I'll pretend that you honestly think that is an
answer, and I'll note that the very same machine may have well
over 100 processes each of which takes 1-2 meg of memory.  If
the machine hits a really-out-of-memory error, I would be much
much happier to see all 100+ of those processes killed, at once,
than the one 40-meg process.

Now tell me how I fix my swap under those circumstances.  If
the answer is "buy infinite memory (ram or disk)", then we don't
need any overcommit policy in the first place.  Note that the
problem might be that these 100 processes start taking up 5 or
10 meg than the 2 meg I'm used to.

> I once described in excruciatingly painful details why a number of
> other techniques would end up being more difficult to implement than
> the above. If you really want to know, check the archives. The very,
> *very* least anyone with *real* interest in this thread can do is
> read the archives on this subject for the past six or seven years.

I once participated in a discussion on this very list where people
would discuss SIGDANGER with some degree of intelligence, instead
of offhand smart-aleck remarks.  That discussion (as I remember)
ended with the conclusion that "SIGDANGER can be useful, but there's
a fair amount of work to do first".  My comment was actually meant as
a follow-up to that earlier discussion, just to see if anything had
happened to get us closer to this.

(as I remember, the first hurdle was something to do with supporting
more signal-types).

I didn't mean to be casting asperisions on the general idea of
overcommitting, or whatever it is that has your shorts all tied
up in a knot.

---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute