On Sat, 18 Mar 2000, Carlos Morgado wrote:
>On Fri, Mar 17, 2000 at 05:33:33PM +0000, Nicholas Vinen wrote:
>>
>> On Fri, 17 Mar 2000, Linda Walsh wrote:
>>
>> > I haven't read through this whole thread, so this may have been
>> > suggested, but why not have a new signal "SIGNMEM". Can't be caught but
>> > can be ignored. Default is to take the signal and terminate the program
>> > that faulted. If ignored, put process to sleep until the memory request
>> > can be satisfied. Then something like 'X' or apache could ignore, while
>> > 'gcc' would just die.
>>
>> Well, it might even be useful to be able to catch it. Example: 'X' gets
>> a SIGNMEM. It responds by freeing any memory it might be using for bitmap
>> caches, font glyph caches, anything unnecessary. When it returns from the
>> signal, the system then has enough memory free to fulfill the request and
>> continue the program. 'X' may have also set a flag somewhere when it
>> caught this signal to tell itself at the first opportunity to shut down
>> and print "low memory: aborting" if this was a desired behaviour. Better
>> than a crash huh?
>> Overall an excellent suggestion I think.
>>
>
>So you have 1 process hogging all the memory and all the others in a rather
>peacefull state. You go OOM and SIGNMEM that process, which obviously ignore
>it. Now you have a system that a) OOM b) with not chance in hell of
>recovering memory, except in the case where a good program frees some
>memory, which wakes up the hog for more hogging.
>Congrats. You now have a program with no runnable processes.
It's not so bad when it is combined with per user resource quotas. The
system doesn't fail. The user fails, and then gets aborted. Since all
processes being signaled should/would be owned by the user (as is the
amount of resources involved) only that specific user would have a
problem. Then the he usual deadlock detection techniques could/would be
used to select a single process to abort.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:26 EST