Dennis Glatting wrote:
> > What is memory exhaustion?
> Uh, when I perform a malloc() and get a NULL back? I
> dunno, what do you call that?

Hitting an administratively enforced resource limitation.

> Why would it kill random processes as opposed to the
> offending process?

The offending process is the first process that causes
a copy-on-write or similar fault, that results in needing
to allocate a backing page for it as a result of the
trap handler.

When you are out of memory, the requesting program can't
be satisfied, and so it gets a segmentation violation for
an access to a non-existant page.

Typically, this will be the first program to request more
resources, after hitting the resource starvation point.

A number of operating systems will allow programs to be
parked "precious".  In AIX, this is done by establishing
a signal handler for the resource starvation condition;
programs without the handler "just die".  Programs with
the handler are permitted to shut down gracefully.  A
"precious" program, such as "init" or the swapper, etc.,
just ignore the signal, and reestablish the handler (if
they suffer from SVR3 signal semantics, and can't do it

Various attempts to proactively kill off "resource pigs"
have had limited historical success (generally, these are
your most precious processes).

Other common approaches are to support the "sticky bit"
on executables, which causes their pages to be loaded into
core, and wired down, so that they can never hit an overcommit
barrier and get themselves terminated; similarly, there are
OS's which permit a command to be run to ensure that resource
reservations exist for a process' resource limits, as set by
the system.  This tends to "waste" resources, since programs
rarely need all of the resources they could possibly ever
need.  The formal name for this last approach is called "The
Banker's Algorithm"; search for that phrase, in conjunction
with the name of its author, Djikstra, and you will find _a
lot_ of information on overcommit architectures.

> Regardless, the code shouldn't be crashing the kernel.


-- Terry

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

Reply via email to