Date: Wed, 19 Mar 2003 15:36:19 +0100 From: Phil Regnauld <regnauld@catpipe.net> To: Wes Peters <wes@softweyr.com> Cc: Juli Mallett <jmallett@FreeBSD.org>, Eivind Eklund <eivind@FreeBSD.org>, Mike Silbersack <silby@silby.com>, David Schultz <das@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c Message-ID: <20030319143619.GA47243@catpipe.net> In-Reply-To: <200303171156.40901.wes@softweyr.com> References: <200303122313.h2CNDHMU046431@repoman.freebsd.org> <20030314012954.A42430@FreeBSD.org> <20030314101857.A98861@FreeBSD.org> <200303171156.40901.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wes Peters (wes) writes:
>
> o Add a flag in the proc struct signalling 'don't kill me'. This flag
> is not inheritable. (I recycled the now-deprecated P_NOSWAP flag for
> this).
>
> o Hack squid and a few other essential and potentially large programs
> (such as bind) to set this flag.
>
> This change effectively stopped our system from committing suicide,
> encouraging it to kill off worker-slave processes that can be restarted
> when load reduces instead of killing the heart of the box. I can work
> up a patch if someone would like to see this on a recent system.
Funny you mention this approach -- I came up with a similar idea
back in November. This is how I formulated it back then:
... Problem with overcommit if that if a process eats ram like a pig, or
leaks, or runs away, it will still be the last process after that (the one
that makes the overflow) to touch a page after the resource hog that buys it.
And there goes X11.
Idea: a "contract" mechanism by which a process registers to the kernel and
says "ok, during my life, I will never go over X MB RAM (effective, not
overcommit)". Warning: this is not a malloc, just a hint.
- if the process respects its contract, stays below X (good memory
policy, reuses its pools to the max, etc...), then when both
VM and physical mem are exhausted, this process will not be lined
up against the wall
- if a process does not respect its quota, it loses its privileges,
and when/if memory runs out, it gets a last cigarette like the others
- if a process comes after the others, and asks for a "garantee" X
which is superior to whatever is left, then the demand is refused.
it's left up to the process to decide what to do
- if all reg'ed processes on the system have resspected their contract,
but there's no more memory anyway, then we have to shoot one --
probably the most recent contractor, or the one eating the least/most
mem (arbitrarily ?)
Applications that would benefit greatly: any large monolithic semi-critical
subsystem (Oracle, X11, ...)
Applications not needing it: any pre-forked base app (Apache et al.)
Cases to manage:
1) P asks 50 MB
uses 40.
VM usage increases. Finally there is only 5 MB left.
P touches 6 MB of pages, i.e. 1 MB too much
=> ?
2) what about forks and exec ?
fork: parent/child relationship, global quota: the parent must
plan usage in VM of all its children (Apache, Postfix, ...)
... or by process ?
exec: new processes not protected by contract unless explicitly told
to be. Global quota inherited, but not duplicated (same area/qty, minus
pages not released by old process).
useful for binaries for which we don't have sources: write a wrapper
for the binary, or use a login.conf demon class, contract for the mem
you need, exec the binary
Questions: has it already been done ?
would it be useful ?
Cheers,
Phil
--
_ _ |_ | regnauld@catpipe.net catpipe Systems ApS |
(_(_||_ | *BSD solutions, consulting, development |
| Tlf.: +45 7021 0050 http://www.catpipe.net/ |
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030319143619.GA47243>