Re: [patch] oom-5

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Wed, 7 Oct 1998 20:34:15 +0200 (CEST)


On Wed, 7 Oct 1998, Andrea Arcangeli wrote:
> On Wed, 7 Oct 1998, Rik van Riel wrote:
>
> >> + * If we can' t free one page we can' t able to
> >> + * free tries page. -arca
> >
> >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.
>
> 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 ;)

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

You can't reproduce it unless:
- you have an awful lot of memory (>128 MB???)
- 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()

Basically, when you have more memory than is scanned
in one try_to_free_page() turn, you can run into the
problem I described...

I hope I have explained the problem now.

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/