lkml.org 
[lkml]   [1998]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Out Of Memory in v. 2.1
On Tue, 6 Oct 1998, Rik van Riel wrote:

>On Tue, 6 Oct 1998, Andrea Arcangeli wrote:
>> On Tue, 6 Oct 1998, Rik van Riel wrote:
>>
>> >It also introduces a new one: having kswapd stop when
>> >try_to_free_page() fails. When try_to_free_page() fails,
>>
>> Tell me how can kswapd free memory if try_to_free_page() fail! If
>> try_to_free_page() fails it means that we really have not enough
>> memory and we _must_ stop.
>
>You forget that try_to_free_page() doesn't scan all memory.
>It also only ages memory if all memory it scanned was touched
>or had a high age. This means that we might need multiple
>scans in order to actually free something.

Yes, you described exactly what' s happening in 2.1.124. kswapd free 1
page every 2 sec but to do that eat all the CPU and not other SCHED_OTHER
process are allowed to run.

>> >Your patch doesn't really fix the bug. It makes sure that
>> >kswapd has complete failures more often, and this can be
>> >considered a bad thing instead of something nice.
>>
>> For what I understand from the code there is a simple function
>> called do_try_to_free_page(). This function when called must try to
>> free a page. When this function fails it means that there isn' t a
>> freeable page.
>
>Nope, it just means that this function didn't encounter a
>freeable page. There might be more memory in the machine
>than what is scanned in one pass of try_to_free_page()...
>
>It could also mean that all memory it saw had a page age of
>> 0, so it couldn't be freed _yet_, this memory _can_ be
>freed on the next pass --> problem solved, if you allow the
>next pass, that is.

I think to have tested things very well these days and from practice I
know that when do_try_to_free_page returns 0 we are wasting our time. Only
1 time over 300/400 do_try_to_free_page used by kswapd return 1 after a 0.
Add some debugging code and you' ll see.

>> Ok I can agree that we could wait two/three consecutive fail of
>> do_try_to_free_page() (for increase the pressure, even if returning
>> at the first fail seems to work just fine) before put kswapd to
>> sleep but this doesn' t change my point.
>
>We've done that before and we removed it from the kernel
>around 2.1.8? because it didn't work. Please re-read the
>archives for a brushup of factual knowledge...
>(this mainly is for the innocent bystanders who are reading
>this -- Andrea probably knows enough to not have to do this)

My first kernel is been 2.0.26 and my first 2.1 is been 2.1.2/3? so I can'
t remeber that ;-).

>Why do you think we should kill the program that generated
>the pagefault? I think that most people would like the
>obvious offender to be killed, if only to minimize the number
>of programs that have to be killed.

Really I don' t care of which process to kill, I only care that my system
handle _well_ and _efficient_ the OOM condition. Sure I don' t want a OOM
killer _daemon_.

My point is that it' s so simple to kill the process that has segfaulted
that it _has_ to work.

>> No. Wrong. If netscape is swapped out and sleeping, killing Netscape
>> would be a wrong choice. Eventually it could be tunable but sure
>> killing Netscape if it' s sleeping it' s a wrong default I think.
>
>If it is swapped out and sleeping, it will have an RSS of 0,
>making it non-interesting for the OOM killer -- have you
>actually read the code?

No. As just said I am not interested at all.

>> The _only_ way an OOM killer could be useful is to avoid killing of
>> X.
>
>This is obviously _not_ true; a lot of sysadmins and other

Yes excuse me you' re right, I should specify that it' s the only thing
that could be useful for _me_.

>You have no way of tellling what other people think is
>most important to them, especially not in the case of
>sysadmins with 15+ years of Unix experience!

I like the GNU/Linux world because nobody care if you have 10 degree or
nothing as me ;-).

>It does. With your patch it kills a random process, with
>my patch it deadlocks for a few seconds and then it kills
>a non-random process -- doing far less harm to the system
>in the long run.

Are you using a kernel daemon? I will __never__ waste _1_ CPU cycles when
the system has tons of memory for doing something that 2.0.35 handle
perfectly!

>Svga programs have IOPL too, they won't be killed by
>my OOM killer. Coding up a bad svga app doesn't really

So you OOM killer will fail. An iopl process could hang the machine.

>count, since it has to run as root -- no good root
>would install a program like that.

So your whole design is broken. The point of OOM is a deadlock caused by a
mistaken. The point is that if you' ll need a svga application that will
monitor something eating tons of memory (eventually caused by a memleak in
a developement phase) the kernel will deadlock as usual right now. The
point is that the kernel must never deadlock due an OOM. So at least fix
your OOM killer now.

>Besides, if it forked over and over, your patch would kill
>it too and the system would be screwed as well, besides,
>your system has _no_ fork-bomb protection, so how is it
>going to help there?

You said me something like "your patch is broken because is not able to
put the screen in text mode". I answered "if my patch is broken that way
your patch is broken too".

Now you say:

"your patch would kill it too"

Yes, I never said that my patch won' t kill it because I want kill it
right now. You are the one that said that your OOM killer is able to
handle console screwup.

And saying:

"your patch would kill it too"
^^^
you say also that _your_ patch would kill it too. But some lines before
you say:

"Svga programs have IOPL too, they won't be killed by
my OOM killer."

Note that you are contraddicting yourself. And if you don' t kill it your
machine will deadlock so killing it is the only solution (at least you' ll
be able to connect via network fine).

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