lkml.org 
[lkml]   [2000]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Avoiding OOM on overcommit...?
    Date
    On Fri, 17 Mar 2000, Michael Bacarella wrote:
    >This was mentioned already, but I haven't seen a really decent reason for
    >why it's not a good idea. Therefore, I'm giving it more airtime.
    >
    >Solution?
    >
    >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.
    >
    >This would of course mean that you'd need a LOT of s/low priority virtual
    >memory "just in case", but the worst case (where all of the committed is
    >actually used) would be rare and only happen in OOM situations.
    >
    >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 would gladly take this option on a production server. I can easily
    >sacrifice slow IDE drives to the VM cause and NFS mount more swap
    >space if need be, without having to worry about random tasks dying
    >if the kernel finds itself low on memory it told a process that it had an
    >infinite amount of.
    >
    >Note, I am saying "OPTION". This should not be the default behavior, but
    >there's certainly no reason why it can't be an option for those of us who
    >will run Linux with swap, on a production machine.

    This IS a solution, though not an "optimal" one. I'm in favor of having
    resource controls that allow tha administrator to allocate resources,
    and be able to know how much memory/swap is required. Still allowing
    overcommit as an option.

    I have no problem with overcommit on a workstation system that is
    dedicated to one user. It is truly horrible to do that to a server,
    whether it is for web usage, mail, DNS, disk, or multiple users.

    >I trust that I will be corrected if I am a dumbass. :)

    Not by me.
    -------------------------------------------------------------------------
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:4.045 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site