Date: Fri, 4 Jan 2008 13:03:01 +0000 From: "Igor Mozolevsky" <igor@hybrid-lab.co.uk> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org>, Jason Evans <jasone@freebsd.org> Subject: Re: sbrk(2) broken Message-ID: <a2b6592c0801040503j650046f5k73895b5b0c84025d@mail.gmail.com> In-Reply-To: <5647.1199451237@critter.freebsd.dk> References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/01/2008, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > SIGDANGER is not what we need. > > What we need is an intelligent mechanism to tell applications what > the overall situation is, so that jemalloc and aware applications can > tune their usage pattern to the availability of physical and virtual > memory. > > Instead of the binary "SIGDANGER" indication we need a more gradual > state, at the very least three stats: "plenty", "getting a bit > tight" and "crunchtime". This makes memory management in the userland hideously and unnecessarily complicated. It's simpler to have SIGDANGER (meaning, free all you can) -> SIGTERM (terminate gracefully) -> SIGKILL (too late, I'm killing you anyway); and maybe a MIB in sysctl like ...vm.overcommit_action ='soft' being SIGDANGER->SIGTERM->SIGKILL and = 'hard' being SIGKILL, so the sysadmin at least has a choice Igor
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a2b6592c0801040503j650046f5k73895b5b0c84025d>