On Wed, 29 Mar 2000 17:37:09 +0100, you wrote:
>James Sutherland wrote:
>> On 28 Mar 2000 00:26:37 GMT, you wrote:
>> >On 21 Mar 2000 23:36:59 +0100, Marco Colombo <marco@esi.it> wrote:
>
>> >reserving some memory only for kernel and/or root, etc, but it will just
>> >lower the chances for OOM, not eliminate it.
>> >
>> >OOM will still happen, and we need some handling when it hits us. killing
>> >random process is at least guaranteed to be fair as far as it goes, but
>> >fairness is not necessarily the most sane thing to do in all cases...
>>
>> Not necessarily "killing" - just "signalling". Properly written, a
>> program should be able to handle the signal and exit gracefully. If it
>> doesn't handle a "something's wrong" signal, can we expect it to check
>> every malloc() call for an equivalent return value?
>
>Have you tried implementing a program that handles SIGBUS? It's a bloody
>nightmare that will drive you insane (especially if you plan on using
>threads).
I wouldn't have suggested SIGBUS for the job. Something equivalent to
SIGLOWMEMORY. Remember, this can only ever be called on a memory
allocation failure (writing to a COW page for the first time, etc.) -
so you couldn't get a loop, provided you initialise all the structures
used directly by the signal handler. (Just after every fork, disable
the handler, touch the structures, reenable it.)
As someone else mentioned, this would be very useful for JVMs,
interpreters, server daemons etc. to trigger garbage collection or
cache shrinkage.
With this signal, you could write a pretty simple wrapper to replace
malloc() etc. with the functionality you want, just by touching all
the memory before returning, and using the signal to cause an ENOMEM.
(snip example code)
>Yes, the second example lacks sigstack etc, but you can assign fixed
>stacks etc. In reality it's very hard to actually overrun your stack if
>you write code knowing it's limited. Other problems include executable
>pages being paged out and then faulted (==SIGBUS with handler on disk
>not in memory). You can mlock() to get around that, but then you need to
>be root, and mlock()'ing of executable pages from devices is broken
>anyway.
Rather than using your own stack, you could just pre-expand your
system-supplied stack to the desired size initially, achieving much
the same. You can then use the stack up to this size without problems
(it's already been allocated). If you overrun this stack, you have
potential problems (if there isn't enough free VM to expand it) - but
that's true of a self-provided stack too.
>Now, which of these two examples do you suppose is easier to write and
>maintain? At any rate, a program which doesn't check the return value of
>malloc/mmap etc is either a quick hack or it's plain BROKEN.
>
>Nobody writes a SIGBUS handler because it's just not practical. If, on
>the other hand, somebody can demonstrate a nice way of doing so, I would
>be happy to use it :)
Not SIGBUS - I was suggesting a new "running out of memory, please
free some now" signal.
I agree that reusing SIGBUS for this would be very hard to program
for, which is why we really need a new signal for it. Having a new
"Memory getting low, please garbage collect etc." signal, OTOH, could
be pretty useful?
James.
-
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 : Fri Mar 31 2000 - 21:00:27 EST