From: Chris Frey <cdfrey@foursquare.net>
To: linux-kernel@vger.kernel.org
Subject: OOM policy, overcommit control, and soft limits
Date: Sat, 31 May 2008 06:27:52 -0400 [thread overview]
Message-ID: <20080531102752.GA25244@foursquare.net> (raw)
Hi,
The kernel provides things like ulimit, overcommit_memory, and the OOM
killer notifications, so in theory memory management should not be a
problem, but from time to time, I have a real need to regain control of
my system when it runs away on me.
I like how mode 2 of overcommit_memory uses the ratio as a boundary limit.
Ideally I would like something like this as a soft limit, so once the
system gets that full, I get a warning.
Here's my ideal OOM flow:
1) set my soft limit to 90% of RAM
2) any malloc that hits this limit first runs through a notification
hook, that talks to a userspace daemon if present,
or just denies the malloc if not
3) the daemon can decide whether to allow the allocation, going
beyond the soft limit
4) the daemon can make these decisions automatically based on
policy (i.e. X always gets the green light), or if we
want to get fancy it can talk to some pre-allocated
GUI to present the decision to the user...
(i.e. Allocate / Deny / Stop / Kill)
5) if the user foolishly keeps allocating, then the current
OOM killer comes into play
I'm sure someone has thought of this before me. Does anything remotely
similar to this already exist? I've googled for OOM policy, but so far
all I've seen is Rusty Lynch's patch from 2003, and really, I want this
behaviour to happen when there is still a bit of memory left, so things
can be dealt with before they are OOM-level dire.
Thanks in advance,
- Chris
next reply other threads:[~2008-05-31 10:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-31 10:27 Chris Frey [this message]
2008-05-31 13:15 ` OOM policy, overcommit control, and soft limits Alan Cox
2008-05-31 16:41 ` Andrea Righi
[not found] <azwvH-5QW-5@gated-at.bofh.it>
2008-05-31 12:48 ` Alan Jenkins
2008-05-31 15:23 ` Alan Cox
2008-05-31 16:45 ` Alan Jenkins
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=20080531102752.GA25244@foursquare.net \
--to=cdfrey@foursquare.net \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.