>should push this into the main kernel right now, IMHO.
>Code cleanup is always a good thing...
>
>> if (gfp_mask & __GFP_WAIT)
>> + {
>
>Just one problem... Hardly anybody uses __GFP_WAIT anymore,
???
#define GFP_KERNEL (__GFP_MED | __GFP_WAIT)
>instead, we let the I/O requests accumulate till we have a
>nice amount and then we flush it. Maybe we want to decide
>this with a flag (agressive) to try_to_free_pages?
I don' t worry too much about swapout performance here. I only care that
everything works fine right now...
>> /*
>> + * If we can' t free one page we can' t able to
>> + * free tries page. -arca
>> + */
>> + if (!do_try_to_free_page(0))
>> + break;
>
>As I pointed out, this is plain wrong in a lot of
>situations. It might work on your machine, but it
>definately will fail on a lot of other machines.
>This is about the only piece of the patch that I
>have real problems with...
OK, thanks for your comment.
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.
As second I can' t reproduce the problem you are reporting here (at least
with oom-5). Could you tell me a way to reproduce it to allow me to tune
things better?
And BTW, my patch still need some other _minor_ improvement, like waking
up kswapd after a process exit() if we are low in memory (I got this idea
this morning while studying Analysis ;-).
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/