From: Rik van Riel <riel@conectiva.com.br>
To: Slats Grobnik <kannzas@excite.com>
Cc: linux-mm@kvack.org, Andrew Morton <andrewm@uow.edu.au>
Subject: Re: [PATCH] a simple OOM killer to save me from Netscape
Date: Thu, 12 Apr 2001 15:25:00 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.4.21.0104121519270.18260-100000@imladris.rielhome.conectiva> (raw)
In-Reply-To: <200104121659.f3CGxX714605@tuttle.kansas.net>
On Thu, 12 Apr 2001, Slats Grobnik wrote:
[snip special-purpose part]
> By running `free -s1' or `top' it's clear that once swap memory gets
> maxed out, *cache* memory size decreases until, at about 4M, mouse &
> keyboard response becomes noticeably sluggish. At cache=3M or less,
> all hope is lost. But at this point, *free* RAM size may not be
> affected much. And since CPU activity is down to a crawl, it may
> take a while to reach minimum (or some small arbitrary figure.)
> So I altered the `out_of_memory' function accordingly, and expect to
> never reboot again. (Except for changing kernels, and power outage.
*nod* We need to OOM-kill before we're dead in the water due to
thrashing.
> - /*
> - * Niced processes are most likely less important, so double
> - * their badness points.
> - */
> - if (p->nice > 0)
> - points *= 2;
> + /* Niced processes less important? Distributed.net would disagree! */
Agreed. A while ago there was a discussion about this and we
agreed that we should remove this test (only, we never got
around to sending something to Linus ;)).
> - /* Enough free memory? Not OOM. */
> - if (nr_free_pages() > freepages.min)
> - return 0;
> + /* Even if free memory stays big enough... */
> + /* ...a cramped cache means thrashing, then keyboard lockout. */
>
> - if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
> + if ((atomic_read(&page_cache_size) << PAGE_SHIFT) > (3 << 20)-1 )
> return 0;
1) you DO need to check to see if the system still has enough
free pages
2) the cache size may be better expressed as some percentage
of system memory ... it's still not good, but the 3 MB you
chose is probably completely wrong for 90% of the systems
out there ;)
I believe Andrew Morton was also looking at making changes to the
out_of_memory() function, but only to make sure the OOM killer
isn't started to SOON. I guess we can work something out that will
both kill soon enough *and* not too soon ;)
Any suggestions for making Slats' ideas more generic so they work
on every system ?
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-04-12 18:25 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-12 16:58 Slats Grobnik
2001-04-12 18:25 ` Rik van Riel [this message]
2001-04-12 18:49 ` James A. Sutherland
2001-04-13 6:45 ` Eric W. Biederman
2001-04-13 16:20 ` Rik van Riel
2001-04-14 1:20 ` Stephen C. Tweedie
2001-04-16 21:06 ` James A. Sutherland
2001-04-16 21:40 ` Jonathan Morton
2001-04-16 22:12 ` Rik van Riel
2001-04-16 22:21 ` James A. Sutherland
2001-04-17 14:26 ` Jonathan Morton
2001-04-17 19:53 ` Rik van Riel
2001-04-17 20:44 ` James A. Sutherland
2001-04-17 20:59 ` Jonathan Morton
2001-04-17 21:09 ` James A. Sutherland
2001-04-14 7:00 ` Eric W. Biederman
2001-04-15 5:05 ` Rik van Riel
2001-04-15 5:20 ` Rik van Riel
2001-04-16 11:52 ` Szabolcs Szakacsits
2001-04-16 12:17 ` suspend processes at load (was Re: a simple OOM ...) Szabolcs Szakacsits
2001-04-17 19:48 ` Rik van Riel
2001-04-18 21:32 ` Szabolcs Szakacsits
2001-04-18 20:38 ` James A. Sutherland
2001-04-18 23:25 ` Szabolcs Szakacsits
2001-04-18 22:29 ` Rik van Riel
2001-04-19 10:14 ` Stephen C. Tweedie
2001-04-19 13:23 ` Szabolcs Szakacsits
2001-04-19 2:11 ` Rik van Riel
2001-04-19 7:08 ` James A. Sutherland
2001-04-19 13:37 ` Szabolcs Szakacsits
2001-04-19 12:26 ` Christoph Rohland
2001-04-19 12:30 ` James A. Sutherland
2001-04-19 9:15 ` James A. Sutherland
2001-04-19 18:34 ` Dave McCracken
2001-04-19 18:47 ` James A. Sutherland
2001-04-19 18:53 ` Dave McCracken
2001-04-19 19:10 ` James A. Sutherland
2001-04-20 14:58 ` Rik van Riel
2001-04-21 6:10 ` James A. Sutherland
2001-04-19 19:13 ` Rik van Riel
2001-04-19 19:47 ` Gerrit Huizenga
2001-04-20 12:44 ` Szabolcs Szakacsits
2001-04-19 20:06 ` James A. Sutherland
2001-04-20 12:29 ` Szabolcs Szakacsits
2001-04-20 11:50 ` Jonathan Morton
2001-04-20 13:32 ` Szabolcs Szakacsits
2001-04-20 14:30 ` Rik van Riel
2001-04-22 10:21 ` James A. Sutherland
2001-04-20 12:25 ` Szabolcs Szakacsits
2001-04-21 6:08 ` James A. Sutherland
2001-04-20 12:18 ` Szabolcs Szakacsits
2001-04-22 10:19 ` James A. Sutherland
2001-04-17 10:58 ` limit for number of processes Uman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.21.0104121519270.18260-100000@imladris.rielhome.conectiva \
--to=riel@conectiva.com.br \
--cc=andrewm@uow.edu.au \
--cc=kannzas@excite.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox