First, let me warn you that this is a often recurring thread. It has
already showed up two or three times this year alone.
Ivan wrote:
>
> I had a look at vm_pageout.c and noticed that situations may occur where
> no process can be killed. I guess that in such situations memory
> allocation requests are simply rejected ( e.g. malloc returning NULL ) .
Err... no. Malloc() does not "call" these functions. By the time a
pageout is requested, the malloc() has already finished. The pageout
is being requested because a program is trying to use the memory
that was allocated to it.
> Is there a reason why this isn't the default behavior in FreeBSD ? i.e.
> why does the system always try to kill a process ?
If no process can be killed, the system will panic (or deadlock).
> Indeed, the 'biggest' process is SIGKILLed without any prior notice. Would
> it be possible to send him a nicer signal first, to let him a chance to
> quit before being killed ?
I'd very much like to see swap space being taking into account in
addition to RSS. A runaway program is more likely to have a low RSS
and a large swap than a large RSS.
Anyway, some Unix systems do send a signal in low memory conditions.
In AIX (the one I'm most familiar with) it is called SIGDANGER, and
it's handler defaults to SIG_IGN.
One reason why we do not do this is the lack of support for more
than 32 signals. Alas, I think we now support more than 32 signals,
don't we? If that's the case, I'd think it shouldn't be too
difficult to make the swapper send SIGDANGER to all processes when
it reaches a certain threshold (x% full? xMb left?).
> A last question, to FreeBSD developpers:
> After a few tests, I came to the conclusion that it's quite easy to crash
> a vanilla FreeBSD system (without any per-user/per-process limits set) by
> simply running it out of swap space ... (the 'kill the biggest process'
> mechanism doesn't seem to always work !?)
'kill the biggest process' should always work. Do you have any test
case where it doesn't?
> Is this a currently addressed issue, or is it simply considered not an
> issue ?
FreeBSD's memory overcommit behavior is not considered an issue by
anyone with the knowledge to do something about it. In fact, these
people consider FreeBSD behavior to be a gain over
non-overcommitting systems (such as Solaris). A lot of people share
this opinion, and some people strongly disagrees.
As for the problems that might result from it, the solution is to
use per-process limits through login.conf, and be a good
administrator.
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Thus, over the years my wife and I have physically diverged. While
I have zoomed toward a crusty middle-age, she has instead clung
doggedly to the sweet bloom of youth. Naturally I think this unfair.
Yet, if it was the other way around, I confess I wouldn't be happy
either."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
