Messages in this thread | | | Date | Wed, 7 Oct 1998 00:30:38 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |