[lkml]   [2001]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: "VM watchdog"? [was Re: VM nuisance]
    In clouddancer.list.kernel, David wrote:

    >>Didn't everyone pretty much agree that if we could turn off overcommit
    >>completely and reliably, that would be the preferred solution ? Simply sig11
    >>the app that's unlucky enough to want more memory than there's in the system
    >>(or, horror, have malloc() fail)
    >>Now, I don't remember the entire thread, but IIRC it was difficult to kill
    >>overcommit completely.
    >The kernel allocates memory within itself. We will still reach OOM
    >conditions. It can't be avoided.

    That doesn't sound good.

    What bugs me about this statement was that until 2.4, I never had
    lockups. I sometimes had a LOT of swapping and slow response, but I
    also knew that running a complex numeric simulation when RAM <
    'program needs' does that. I accepted it and tended to arrange such
    runs in my absence. Now I find that I get some process nuked (or
    worse - partially nuked) even after increasing to 4x swap and
    eliminating lazy habits that would leave some idle process up for a
    few days in case I needed it again (worked fine in 2.0.36). There are
    _alot_ of good things in 2.4, but sometimes....

    Does your statement imply that a machine left "alone" must eventually
    OOM given enough runtime?? It seems that it must.

    2.4 VM: "I'm sorry Dave ... I'm afraid I can't do that."

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

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