Re: sbrk(2) broken

In message <86myrlahee.fsf_at_ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr
ites:
>"Igor Mozolevsky" <igor_at_hybrid-lab.co.uk> writes:
>> Broadcasting SIGDANGER would be a much better option; followed by
>> SIGTERM to the memory hogger (to allow for graceful termination) and
>> only then SIGKILL. I can imagine a few (legitimate) scenarios when a
>> user process would want to hog as much RAM as possible...
>
>We don't currently have SIGDANGER, but the signal code was rewritten
>years ago to allow more than 32 signals precisely for the purpose of
>implementing an AIX-like SIGDANGER.  This wasn't done, however, and
>eventually SIGTHR was the first new signal to take advantage of the
>rewritten code.

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".

Having a signal to indicate changes of the state may make sense,
but in a crunch, you don't want to wake all processes and page them
in, just to tell them that you're short on memory, it would have
to be a signal that doesn't schedule the recipient process until
something else does.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.