If __get_free_pages() returns NULL, it can be caused by
multiple things. One of them is that we're OOM, another
is a sudden burst of memory allocation which we can't
keep up with (but of which we can easily recover).
My check is there to test for the second scenario (and put
the user process to sleep if we're in that situation).
> Obviously you never seen a failed process allocation because:
I have, with 2.0 and 2.1.8x I saw them all the time. I
don't want to go back to those times, just because kswapd
eats a bit much CPU time on some systems...
> And note that if you have not changed the force_sig() from
> linux/mm/*.c in your patch, and your patch works fine, you have
> proved what I said!
I have not needed to change it, because kswapd does it's
work just fine now. With your patch, we're essentially
back to the 2.1.8x days -- that is, if you patch is
applied blindly, without making the needed checks before
we start killing.
> So your whole OOM killer patch is a screw up of the linux mm. It' s
> far from fix the deadlock.
My patch is designed to handle OOM, your patch is designed
to fix the deadlock. My patch was not made to fix the
deadlock.
Why you call it a screw up is beyond me, I could just
as well say it of your patch, for reintroducing a bug
that we removed ages ago. Note, however, that I won't
say something like that and that I am actively pointing
out that single error in your patch _and_ have provided
a fix for that that doesn't interfere with the advantages
of your patch.
> >chance of that happening is increased from virtually
> >impossible to just very unlikely, but the chance of the
> >bug manifesting itself _has_ increased with your patch.
>
> Your OOM hide the deadlock. This is a bug.
Yes, I know it is. My point is that _your_ patch
reintroduces a bug that we're all very glad to have
gotten rid of. Then I go on to hand you the fix,
only to have my arguments completely ignored by
you and to be continuously insulted with blatant
statements like this.
If you don't want to answer to the real questions
that I give, then don't answer the post at all.
You have been trimming the real arguments from
my letters and have only responded with troll-like
"BUG BUG BUG" statements.
We really should get over this before it turns into
a flamewar...
> >It almost seems like a bug doesn't exist until you can
> >see it with your own eyes -- this is a completely
>
> Infact I am wating for bug reports.
You don't need to. Just read the linux-kernel archives
of the 2.1.8x era. The bug I mentioned is out in the
open and gets fixed in the early .90s...
> >When programming for such a wide usage pattern, we
> >just _have_ to take theoretical bugs into account
> >as well... (QED)
>
> This is why I don' t want your patch that leave the dealock OOM bug
> in the kernel.
I don't want it in too. What I want in is a patch that
combines the removal of the deadlock (your patch) and
the removal of the unneeded killing bug (my piece, as
outlined several messages ago).
I never proposed that my patch should go in as is,
thereby ignoring your patch. On the contrary, your
patch does fix a very nasty bug and should definately
be included soon -- just not in it's current patch, as
that would mean the reintroduction of another bug,
one that is very easy to fix.
> And note that the mm layer must be stable, not deadlock, not cause
> starvation, must be efficient, and must work in the most of cases
> (it has not to be perfect, it can' t be perfect since phys memory is
> finite and all algorithms are heuristic). I am not sure to be right
> here but sure this is my thought.
I agree with you, our difference of opinion mainly seems
to be over to what lenght we should go in covering 'most'
cases. You want to stop fixing at a certain point (say 99.99%),
but I want that last bug squashed out, in order to gain a few
more 9s behind the decimal point...
Your point is keeping code complexity down, but in this case
that's moot, because my code will only be called when we're
already in some kind of trouble -- that is, hardly ever on
normal machines.
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/