Date: Sun, 11 Apr 1999 17:04:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brian Feldman <green@unixhelp.org> Cc: current@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <199904120004.RAA08629@apollo.backplane.com> References: <Pine.BSF.4.05.9904111330290.14477-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:It seems that something has broken the good ol' swap behavior. For instance,
:I have my user-limits set to unlimited and I run something which uses up
:all RAM. Mallocing never FAILS in the program, as brk() doesn't fail, as etc
:etc etc. But mallocing continues, all swap space gets used, and both the
:runaway process and the next biggest gets killed (XF86, of course).
: Matt, perhaps you can shed light on
: a. why mallocs still succeed after
:swap_pager: out of swap space
:swap_pager_getswapspace: failed
: is displayed
: b. why the process continues and gets killed TWICE, or two different
: processes get killed
:?
:
: Brian Feldman _ __ ___ ____ ___ ___ ___
The thing with the processes getting killed twice or two different
processes being killed is due to the latency between sending the signal
to kill the process and the process actually going away. In order to be
killed, the process must be woken up and allowed to run.
malloc() still succeeds because it isn't actually touching the new memory,
and so the system doesn't actually reserve the memory as of the time of
the system call. That is done by the user program later on after malloc()
returns. malloc()'s limitations are based on the process resources, not
available memory.
It would not be appropriate to make malloc() fail in this situation because
this would result in N random programs getting malloc() failures rather
then one or two processes getting killed. Having N random processes get
malloc() failures can lead to serious instability with processes.
What might help in a situation like this would a way to flag certain
processes as being 'very important' ... that should only be killed as
a last resort, even if they have a relatively large RSS.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904120004.RAA08629>