Re: OOM in 2.2.14

From: Mike A. Harris (mharris@meteng.on.ca)
Date: Sat Jul 08 2000 - 06:46:31 EDT

  • Next message: Mike A. Harris: "Human Genome OOM solution?"

    On Sat, 8 Jul 2000, David Bronaugh wrote:

    >When talking about slow mem leaks and such, I agree with Mike
    >A. Harris. There should be a userland daemon to track free
    >memory and, if it falls below a critical level, add more swap.

    Keep in mind that I'm not suggesting this as a general solution
    for everyone though.. just to suit my personal OOM problem. This
    solution of dynamic swap is NOT good enough for all OOM problems
    in all situations. It assumes one has disk space in abundance
    with which to steal from, and it assumes that a user is sitting
    at the machine to notice something going awry. Such a daemon
    could send an email, play a wav file, or do something else to
    alert the user of a potential upcoming OOM situation.

    This is ok for a hacker workstation, but certainly NOT for joe
    blow, or a Windows user. It also is no good for busy servers,
    and other unattended machines. Reason being that if apps require
    more than the given VM, there is a good chance it is a true
    runaway app, and the dynamic swap won't help at all. It will
    just delay the inevitable.

    My solution IMHO is only good if the app causing the OOM - isn't
    out of hand, but rather just being hungry with memory... dynamic
    swap might just increase the VM pool large enough for the app to
    do its deed without causing the system to OOM. Most of my OOM
    cases have been ones fitting this description I believe.

    The other case where it is good is if a true runaway app goes in
    an infinite loop stealing memory, or if a memleaker gradually
    uses up VM. This buys an interactive user some time to try and
    manually decide how to fix the problem before it goes too
    far. The audio alarm would be a cool benefit indeed.

    This solution however, is a userland issue - a potentially useful
    application (daemon), not really a kernel solution. I think it
    will be a decent solution to my problem though.

    >This seems like a sensible solution, as it is quick and, as it
    >is not in the kernel, it is easy to disable or enable without
    >rebooting (god forbid! :). You can't have the solution in the
    >kernel simply because it's not kosher for the kernel to do such
    >things (sorry if i'm saying things other people already know).
    >
    >Anyways, I'll end my little rant. I'd be interested to hear comments on
    >this.

    Well, I pretty much agree with all that. I wouldn't dream of
    sticking anything like this in-kernel. I'll leave the in-kernel
    OOM stuff to someone who sleeps with printouts of the vm code
    beside them in bed..

    ;o)

    Take care all,
    TTYL

    -- 
    Mike A. Harris                                     Linux advocate     
    Computer Consultant                                  GNU advocate  
    Capslock Consulting                          Open Source advocate
    

    I've overclocked my keyboard interface. It's quite messy dipping my hands into the mineral oil, but *MAN* is my keyboard ever fast now! - Anonymous Coward

    - 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 : Sat Jul 08 2000 - 06:52:22 EDT