Messages in this thread |  | | | Date | Wed, 7 Oct 1998 20:34:15 +0200 (CEST) | | From | Rik van Riel <> | | Subject | Re: [patch] oom-5 |
| |
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/
|  |