> 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/