Re: Overcommitable memory??

From: James Sutherland (jas88@cam.ac.uk)
Date: Tue Mar 21 2000 - 18:53:26 EST


On Tue, 21 Mar 2000 14:34:20 -0400, you wrote:
>"Rask Ingemann Lambertsen" <rask-linux@kampsax.k-net.dk> said:
>> 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.
>
>What _do_ you do then if Jane runs over her memory quota?
>
>> 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.
>
>There are several points where memory is allocated, f.ex. expanding the
>stack. There is simply no way in Unix to intercept that sanely AFAIKS, so
>the "nice proggie steps down on memory use" isn't always possible anyway.
>
>BTW, could you please point at a clean example of a program in actual use
>that handles freeing up memory when OOM looms? Would be useful to have
>handy...

A description of one was just posted to this thread. On malloc()
failure, it starts diverting new connections elsewhere and garbage
collecting itself. Quite nice, although it should do so before
malloc() starts failing...

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