Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2003 18:09:30 +0100
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        "Daniel C. Sobral" <dcs@tcoip.com.br>
Cc:        Garance A Drosihn <drosih@rpi.edu>, 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 ... SIGDANGER 
Message-ID:  <7901.1047661770@critter.freebsd.dk>
In-Reply-To: Your message of "Fri, 14 Mar 2003 14:03:23 -0300." <3E720B5B.8090200@tcoip.com.br> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <3E720B5B.8090200@tcoip.com.br>, "Daniel C. Sobral" writes:

>There have been three suggestions to deal with low memory problem:
>
>* First, one way of telling the kernel that a certain process should be 
>excluded from the processes that can be killed under low memory conditions.
>
>* Second, SIGDANGER.

malloc(3) keeps a (small) cache which can be flushed on SIGDANGER.

>* Third, a sysctl to prevent overcommitting. With this on, memory would 
>be always immediatly allocated, instead of on-demand. With this, no 
>application would ever be killed. Either it aborted because it couldn't 
>allocate more memory, or it didn't. Since this can lock out users from a 
>machine, some of those that implemented this had a sort of reserve for 
>an interactive root process (which could still get exhausted, but whatever).

* Fourth: A cheap syscall or sysctl which can be used to get a real-time
qualified answer to the simple question:  Is the system short of RAM ?

Many programs (directly or implicitly through the use of malloc(3))
can adapt their behaviour, but lack the means to when to do that.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@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.

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?7901.1047661770>