Date: Fri, 14 Mar 2003 14:15:07 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, "Daniel C. Sobral" <dcs@tcoip.com.br>, Juli Mallett <jmallett@FreeBSD.org>, Eivind Eklund <eivind@FreeBSD.org>, David Schultz <das@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm ... SIGDANGER Message-ID: <20030314140414.V4480@odysseus.silby.com> In-Reply-To: <p05200f2bba97e5a92150@[128.113.24.47]> References: <8023.1047662161@critter.freebsd.dk> <p05200f2bba97e5a92150@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Mar 2003, Garance A Drosihn wrote:
> The web page I gave in my other message also talks about a
> 'psdanger' routine, which sounds like it might be what you're
> talking about.
>
> [of course, as a userland-type-of-programmer, I'm hoping some
> kernel-type will get excited about the idea and implement the
> same set of ideas for FreeBSD. :-)]
>
> --
> Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
> Senior Systems Programmer or gad@freebsd.org
> Rensselaer Polytechnic Institute or drosih@rpi.edu
I'm really not sure how much of a help this SIGDANGER or whatever will be.
As I see it, there are two cases of OOM:
1. Heavy load, lots of busy processes, all legitimate.
- Nobody has complained about this case having problems.
2. Light load, then some program goes crazy and forks / chews up ram. X
gets killed.
- I think this is what people are complaining about.
In case #2, SIGDANGER wouldn't help much; how much ram can the actively
running, legitimate programs really save?
What might be a good solution is to use some sort of statistics basic
heuristic when determining what to kill.
For example, say we have these processes:
sshd - 2916K
XFree86 - 21876K
kdeinit - 13424K
lots more kdeinits...
Then we'll have 300 of:
forkbomb - 2000K
Clearly, our OOM killer would start killing X, then kdeinit, and only then
start working on the forkbombs.
What might work well is to have additional fields somewhere which store
what a process's memory usage has been on average over time. The top
three processes listed would all have averages == current memory usage,
and would be ignored. Instead, the OOM killer would concentrate on the
forkbombs, which would have 2000 - 0 = 2000 as their short-term memory
usage increase.
I think a system like that have a behavior closer to what is desired.
Mike "Silby" Silbersack
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-src" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030314140414.V4480>