lkml.org 
[lkml]   [2004]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] oom killer (Core)
    On Thu, Dec 02, 2004 at 07:55:16PM +0100, Thomas Gleixner wrote:
    > On Thu, 2004-12-02 at 19:08 +0100, Andrea Arcangeli wrote:
    > > OTOH we must not forget 2.4(-aa) calls do_exit synchronously and it
    > > never sends signals. That might be why 2.4 doesn't kill more than one
    > > task by mistake, even without a callback-wakeup.
    >
    > I just run the same test on 2.4.27 and the behaviour is completely
    > different.
    >
    > The box seems to be stuck in a swap in/out loop for quite a long time.
    > During this time the box is not responsive at all. It finally stops the
    > forking after quite a long time of swapping with
    > fork() (error: resource temporarily not available).

    Fork eventually failing is very reasonable if you're executing a fork
    loop.

    >
    > There is no output in dmesg, but I'm not able to remove the remaining
    > hackbench processes as even a kill -SIGKILL returns with
    > fork() (error: resource temporarily not available)
    >
    > I'm not sure, which of the two scenarios I like better :)

    Please try with 2.4.23aa3, I think there was some oom killer change
    after I had no resources to track 2.4 anymore. I'm not saying 2.4.23aa3
    will work better though, but I would like to know if there's some corner
    case still open in 2.4-aa. Careful, 2.4.23aa3 has security bugs (only
    local security of course, i.e. normally not a big issue, sure good
    enough for a quick test).

    I doubt your testcase simulates anything remotely realistic but
    anyway it's still informative.

    What I'm simulating here is very real life scenario with a couple of
    apps allocating more memory than ram.

    > FYI, I tried with 2.6 UP and PREEMPT=n. The result is more horrible. The
    > box just gets stuck in an endless swap in/swap out and does not respond
    > to anything else than SysRq-T and the reset button.
    >
    > With the callback the machine did not come back after 20 Minutes.

    Was the oom killer invoked at all? If yes, and it works with preempt,
    that could mean a cond_resched is simply missing...

    > You meant the one in badness() right ?

    yes.

    > Well it makes it better, but I was able to have a second invocation
    > before the first killed tasks exited. That's simple to explain. The task
    > is on the way out and releases resources, so the VM size is reduced and
    > the killer picks another process.

    That's trivial to fix checking for PF_DEAD/PF_EXITING.

    > > I'd rather fix this by removing buggy code, than by adding additional
    > > logics on top of already buggy code (i.e. setting PF_MEMDIE is a smp
    > > race and can corrupt other bitflags), but at least the
    > > oom-wakeup-callback from do_exit still makes a lot of sense (even if
    > > PF_MEMDIE must be dropped since it's buggy, and something else should be
    > > used instead).
    >
    > I think the callback is the only safe way to fix that. If PF_MEMDIE is
    > racy then I'm sure we will find a different indicator for that.

    The callback adds overhead to the exit path. Plus strictly speaking it's
    not actually a callback, you're just "polling" for the bitflag :)

    > Yep, but the reentrancy blocking with the callback makes the time, count
    > crap and the watermark check go away, as it is safe to reenable the
    > killer at this point because we definitely freed memory resources. So
    > the watermark comes for free.

    You can get an I/O race where your program is about to finish a failing
    try_to_free_pages pass (note that a task exiting won't make
    try_to_free_pages work any easier, try_to_free_pages has to free
    allocated memory, it doesn't care if there's 1M or 100M of free memory).
    If you don't check the watermarks after waiting for I/O, you're going to
    generate a suprious oom-killing. Your changes can't help.

    Note that even the watermark checks leaves a race window open, but at
    least it's not an I/O window. While try_to_free_pages can wait for I/O
    and then fail.

    I'll add to my last patch the removal of the PF_MEMDIE check in oom_kill
    plus I'll fix the remaining race with PF_EXITING/DEAD, and I'll add a
    cond_resched. Then you can try again with my simple way (w/ and w/o
    PREEMPT ;).

    Thanks for the great feedback.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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