lkml.org 
[lkml]   [1998]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] my latest oom stuff
    On Sat, 24 Oct 1998, Linus Torvalds wrote:

    >The thing is, kswapd shouldn't even _allow_ that kind of endless looping.
    >It forces itself to sleep at regular intervals by doing
    >
    > current->state = TASK_INTERRUPTIBLE;
    > schedule();

    I tell you it in another way ;-):

    kswapd process<n>
    ------------------------- -----------------
    __get_free_pages()
    woops there is no memory in the free
    memory area struct so wakeup kswapd
    run for 1/2 sec in shrink_mmap()
    and swapout()
    OK now we have lost 1/2 sec so
    we can return to sleep
    schedule()
    failed allocation, we are unlucky this
    is not going to kill the process
    .. other misc things for a usec ...
    __get_free_pages()
    woops there is no memory in the free
    ............ loop ...............

    And note that after the schedule() probably it will be another eating
    process that get scheduled (so the failed allocation get delayed very
    more).

    Having kswapd at no-RT priority should help allowing other process to run
    a bit more in the middle schedule(), but since the dynamic priority was
    setting an high priority for kswapd (counter = prio << priority), when the
    system is oom probably kswapd will run at first as with RT prio. So a
    static priority would be better according to me. Or we could play with
    the ->priority parameter but not with the ->counter parameter in order to
    give your kswapd no-RT patch more chance of success.

    But my way is still to make kswapd to sleep RT and to learn kswapd when to
    stop.

    >However, it can easily be that the "tries" in between are too large, and
    >that it ends up using 99.99% of all CPU time due to not sleeping often
    >enough. The "tries" calculations were done based on an earlier pattern of
    >invocations, and I suspect "tries" is overlarge.

    Hmm, it could be the shrink_mmap() shift factor that it' s too big too.
    But really, changing tries to tries/2 or decreasing of a *2 the
    shrink_mmap() path will make no big differences, the only important thing
    is to stop kswapd when it' s running all the time. As just said we can use
    a more sofisticate heuristic than mine ;-) to stop kswapd.

    >But I suspect that the REAL bug is that there may be code-paths that busy
    >loop forever if they get NULL from __get_free_pages(). That's bad. We
    >found and fixed one in the TCP code earlier, and the way to figure them
    >out is to add a printk() (or a stack trace, in fact) to the NULL return
    >case in __get_free_case() and see if you see an endless stream of them
    >when the machine locks up.
    >
    >The thing is, that I suspect that your patches avoid the problems not by
    >being strictly correct, but by hiding the above kind of endless loops by
    >letting processes die before the bad behaviour gets to instantiate itself.
    >And that also means that the endless loop can still happen, it's just
    >harder to see.

    I instead think that it' s the stock kernel that hide such kind of endless
    loop bugs since it like to loop in kswapd instead of failing an
    allocation. With my patch get_free_pages should be more friendly to return
    NULL and so such kind of bugs should rise more easily.

    I tried now and while the system is oom get_free_pages() got recalled only
    4/5 consecutive times every minutes or more. Even if would be a loop that
    is causing the stall, kswapd give that loop no chance to run and that has
    to be fixed as first thing I think.

    Andrea Arcangeli



    -
    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:45    [W:6.060 / U:0.624 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site