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:0.240 / U:0.068 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site