Messages in this thread | | | Date | Wed, 7 Oct 1998 07:54:37 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: Out Of Memory in v. 2.1 |
| |
On Wed, 7 Oct 1998, Andrea Arcangeli wrote:
> 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.
On _your_ machine, not on mine or on someone else's.
> Add some debugging code and you' ll see.
I did something like that for the OOM killer patch and had a few people test it. Their results were very different from both mine, yours and eachother's. There just isn't anything you can say with certainty from tests on just your own machine.
> >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 ;-).
Uhm, nope. I mean 2.0.8x, where x is something. You were there, I'm quite sure of 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_.
Well, some folks _do_ care what process get's killed. That's why I implemented the OOM killer code. It's not in a daemon, but it runs inside kswapd's context.
> My point is that it' s so simple to kill the process that has > segfaulted that it _has_ to work.
But what if no process pagefaults and the memory is allocated by the kernel?
> >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.
Then you shouldn't make judgements about it. I can agree with the fact that you're not interested in it, but not with the fact that you are making judgements about code you've never actually seen.
> >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!
2.0 doesn't handle it perfectly, with 2.0 a random process get's killed -- this is usually worse than killing a carefully chosen process.
> >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.
Not unless it would use _all_ of memory.
> >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
My point is that root can do something like "cat /dev/random > /dev/mem" anyway, so we shouldn't care that much about what root can or can't do.
User processes can't get IOPL, so mere mortals should be unable to crash the machine.
> >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".
A small correction seems to be in order here, I said something like "With your patch there's the possibility of killing X, even when there is loads of free swap left".
> 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.
No, I said that my patch would usually _avoid_ console screwup by not killing X. It obviously can't _handle_ it, that's something completely different.
> you say also that _your_ patch would kill it too. But some lines > before you say:
Uhm, nope. With my patch and the SVGA fork-bomb, the machine would end up dead. With your patch and the SVGA fork-bomb, the machine would end up a little bit less dead, but just about as useless...
> 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).
With a fork-bomb, it doesn't matter if you kill a few instances of it; the other ones will fork all over again and again and again ad nauseum...
And I'm not contradicting myself -- please read before posting.
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- 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/
| |