On Tue, 21 Mar 2000 16:44:28 +0100 (CET), you wrote:
>On Tue, 21 Mar 2000, James Sutherland wrote:
>> On 21 Mar 2000 13:40:28 +0100, you wrote:
>> >Den 20-Mar-00 18:44:28 skrev Horst von Brand følgende om "Re: Overcommitable memory?? ":
>> >> Jesse Pollard <pollard@cats-chateau.net> said:
>> >
>> >> [...]
>> >
>> >>> YOU ARN'T OOM - a specific user is out of resources, not a catastrophic
>> >>> failure.
>> >
>> >> If the user's programs get killed, they'll be pissed off.
>> >
>> > And for a good reason too. So don't kill the user's programs. That's why
>> >Jesse and others would really like per user memory quotas, just as you have
>> >per user disk space quotas. If you can disable overcommit, the program is
>> >in control of what happens when it can't get the amount of memory it would
>> >like. If you also add per user memory quotas, the system administrator can
>> >prevent a single user (or another finite number of users) from using all
>> >memory.
>>
>> The process CAN be told there isn't enough memory to do what it wants.
>> Just signal it (with a signal it can catch.) It can then use that
>> signal to trigger garbage collection (if it's an ML or Java VM, for
>> example), shrink the cache (an music player), reduce spare processes
>> (Apache), whatever.
>
>Interesting. The page fault routine should trigger a signal to the process
>that caused its invocation. And what even makes you hope that that
>process won't page fault again executing the signal handler (pieces of
>code and data that have been much likely paged-out months ago)?
>
>We are not short of memory. We're short of swap. paging-out is the problem,
>not paging-in.
Where did you get that idea? This situation is "out of RAM+swap". No
RAM free, no swap free, nothing can be allocated. Nothing to do with
paging, either - you can shuffle the memory around fine, the problem
is just that there isn't enough to go round.
>> IMO, it's much better to get a signal which means "we're getting short
>> of memory, folks", which can be handled in ONE place, rather than
>> returning 0 as a pointer - which many apps then try to dereference,
>> ending up segfaulting themselves anyway.
>
>"many apps" do not check malloc() return values? I don't call them apps,
>I call them first time students exercises. B-)
>They're are not able to check malloc() return value but they can setup a
>signal handler that triggers runtime a GC() clever enough not to page
>fault itself? I don't follow you.
If they don't bother handling errors of either sort, they just get
terminated with a signal anyway. If they are careful enough to check
malloc() every time, they would handle SIGBUS as well.
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 : Thu Mar 23 2000 - 21:00:35 EST