>> As first thing I have to say that I can live with a kernel that
>> segfault too early a leak-malicious-proggy but I can' t with a
>> kernel that deadlock if I run the same malicious proggy.
>
>Maybe you can live with a kernel that fails to free memory
>when we have lots of it, but I know _I_ and a lot of other
>folks can't. I agree with the second part though ;)
Probably I am still bad in English. I try again:
You said me:
"As I pointed out, this is plain wrong in a lot of
^^^^^^^^^^^
situations."
_Assuming_ this is 100% right, what do you choice between these two
options?
1. deadlock
2. fail allocating memory
And btw I can' t reproduce (2) here. If somebody that is using my
patches has problem (2) tell me please.
>You can't reproduce it unless:
>- you have an awful lot of memory (>128 MB???)
64Mbyte here. Send me additional RAM (and a new motherboard/CPU since my
P5 board doesn' t handle tons of RAM I think) and I' ll be happy to work
hard all the time with _my_ CPU loaded at 100% to fix the problem ;-).
>- set the settings for the {page,buffer}out-weight in
> /proc/sys/vm/swapctl low enough (something like 512
> for your machine???) so that kswapd scans less than
> all memory on one try_to_free_page()
That' s a completly bogus argument. The sysctl are avaible to make the
system working not to prove that the MM is buggy because doesn' t work
with some malicious setting.
I am pretty sure that there are many ways to cause also the _stock_ kernel
to fail allocating RAM using bogus sysctl values (like setting freepages
min = 0 low = 0 max = 0).
>I hope I have explained the problem now.
The problem is that more pressure would cause tons of not needed
starvation here. I think my patch is the best/cleaner solution now and
should go in. We are just very near to deadlock here using my latest
patch. Only more kswapd pressure is not the solution. I' ll eventually
think something in the next days even if it' s _impossible_
(unfortunately) for me to try code on more powerful hardware so you' ll
have to do that for me (only if I' ll produce something of course).
And btw nobody other you complained about failed ram allocation when the
system really was _not_ oom. Is there somebody out there with more than
128mbyte of ram (as Rik said) that applyed my patch and can reproduce Rik'
s problem with my lastest patch? I ask this because I had instead private
very good reports (also regarding the network allocation that seems fine,
so probably I' ve done a gitch in the developement stage or gcc/egcc (I
tried both) miscompiled something confused by the nested
`while'/`switch').
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/