[lkml]   [2000]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: Avoiding OOM on overcommit...?
    > > Alan, does it make sense, in ANY situation, to disable 
    > overcommit? Because
    > > AFAIK, a system without overcommit would always have to kill processes
    > > before an equivalent overcommitting system would.
    > >
    > > It seems to me that this whole overcommit debate is just
    > avoiding the real
    > > problem, which is how to decide which tasks to kill.
    > The whole point is: in a system without overcommit, a process is never
    > killed for overcommitting.
    > There's no issue about which process to kill because you never have to.

    You are assuming that every bit of code is able to handle malloc
    failures intelligently. Firstly there is a lot of code in the wild
    that just doesn't expect malloc to fail (not unreasonably since the
    author _knew_ he wasn't going to get anywhere near exhausting the
    vm heap). Secondly the code paths that involve malloc failures are
    some of the least tested. Thirdly the most common way of handling
    a malloc failure is to simply kill the process, gracefully or otherwise.

    So, if you use no-overcommit you either have a very specialized
    system running carefully chosen software or you have a system which
    will still fail but your only way of controlling the failure - trying
    to keep it running as best you can then _choosing_ something "sensible"
    to kill - has been removed.

    Those who want no-overcommit are free to implement it and use it
    of course, but it isn't the ultimate solution for a general purpose
    OS that some people seem to think.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.021 / U:12.332 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site