There is obviously a problem when all swap is exhausted.

The only solution is to allow the additional memory *use* to succeed AND
to warn the sysadmin that ALL virtual memory has been exhausted.

The only way to do this is to be able to allocate extra virtual memory.
I'd vote for a system that would create swap files in the largest mounted
read/write filesystem of type UFS or in the filesystem of my choice.

There would be a systctl to set the limits on how much space to allocate.
Possibly a setting for size and number of emergency swap files.

When the time comes for killing processes, you should be able to specify
that certain processes (by name) are "precious" and that processes owned
by particular users and/or particular login classes are in the last resort
or first resort for killing.

I dont think it's worth trying to signal with a different signal because
only FreeBSD specific programs will know what to do when signalled in such
a manner.  I suppose you could signal prior to killing as another layer to
my dream system.

Warner Losh wrote:
> In message <> Mikhail Teterin writes:
> : Then, one can write a safe malloc, which will install the signal
> : handler, and touch every page in the the memory referenced by the
> : to-be-returned pointer. If the signal handler is invoked in the
> : progress, the to-be-returned memory must be returned back to the
> : system and NULL should be returned to the caller.
> This won't work all the time.  FreeBSD overcommits swap space and you
> may get a SIGKILL even if you've touched all the pages.  FreeBSD kills
> processes when swap space runs out.
> : However, my (in)ability to propose anything remotely sensible does
> : not change the facts established in this painful thread. That our
> : malloc does not conform to standards (for whatever reasons), and
> : that something should be done about it. That "something" must start
> : with documenting the flaw...
> The behavior is documented:
>      The malloc() and calloc() functions return a pointer to the allocated
>      memory if successful; otherwise a NULL pointer is returned.
> What the system does when it has resource shortages is beyond the
> scope of the ANSI-C standard, so I don't see why you say that
> FreeBSD's malloc isn't standard conforming.
> Warner
> To Unsubscribe: send mail to
> with "unsubscribe freebsd-current" in the body of the message

| Work: | Home: |
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973

To Unsubscribe: send mail to
with "unsubscribe freebsd-current" in the body of the message

Reply via email to