lkml.org 
[lkml]   [2000]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Avoiding OOM on overcommit...?
Date
On 18 Mar 2000 01:11:59 -0500, you wrote:

>In article <Pine.BSF.4.05.10003171855400.9271-100000@bsd1.nyct.net>,
>Michael Bacarella <mbac@nyct.net> wrote:
>>
>>No overcommit of VM. Yes! This would be HORRIBLE for performance, but ONLY
>>if you're actually allocating the memory to the process. If you don't
>>actually allocate it, but in fact just ensure that it could allocate it
>>in the future, you take no performance hit and gain that much stability.
>
>I agree with you Michael. This would make it possible to write
>applications which are robust about memory allocation, since they will
>know at malloc time whether they have the memory they requested and can do
>intelligent things (e.g., purge buffers, alert the user, wait, etc.)
>beyond merely catching SIGTERM and exiting gracefully.

You get this behaviour anyway if you just touch the memory when you
allocate it - perhaps using a wrapper or a patched C library?

Also remember that stack space is demand allocated anyway. How much
stack space do you allocate to each process, if it is going to be a
hard limit (overrun it and die)?

>Overcommitting memory is the moral equivalent of writing bad checks and
>praying there will be money to cover them before they are cashed. It's
>completely irresponsible-- and when it fails, it really bites down hard.

Not really; it's more like carrying a credit card with a higher credit
limit than the balance in your cheque account. If you max out your
card, then you have a problem - but better to have a credit facility
than to find yourself hitting a hard limit earlier on, because you
weren't carrying enough cash at the time.

>>While, yes, a 40 meg process that fork()s will have to make sure that
>>there are 40 megs of VM free, it doesn't mean that COW cannot be used,
>>and it does not mean all 40 megs will have to be paged in.
>
>I know I'm going to get pelted with rotten tomatoes for saying so, but
>if you're talking about fork+exec, vfork() was an obscenity but it did
>handle the trivial case quite well.

Now we'll take a WWW server, with 100 processes forked, all sharing
most of the image. You just blew 2Gb or so of my swap space, to
achieve - nothing.

>>I trust that I will be corrected if I am a dumbass. :)
>
>No, I think you're spot-on.

Demand allocated memory is definitely preferable in most situations.
There may be specialist applications where you want precise control
over how much VM and stack you have, but not in the normal kernel
ATM...


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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site