Date: Wed, 22 Sep 1999 18:22:17 +0200 (MET DST) From: Ivan <Ivan.Djelic@prism.uvsq.fr> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R Message-ID: <Pine.SUN.3.95.990922174139.961A-100000@bonnard.prism.uvsq.fr> In-Reply-To: <37E8F645.7437D0D9@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Sep 1999, Daniel C. Sobral 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.
Of course I didn't mean that malloc() calls the pageout daemon ... I
simply meant that if no more memory space can be regained (in particular
by killing a process) then at some point memory allocations will be
refused -- or else, when does malloc() ever returns NULL ?!
> > 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?).
Or even simply send SIGTERM for instance before SIGKILL ... at least,
that would be understood by many processes (such as the X server).
> > 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?
>
I logged in and ran this little program this morning on a FreeBSD 3.2R box
(128 MB RAM, 300 MB swap) (try this at home :-):
#include <stdio.h>
#include <assert.h>
#define ISIZE 180*1024*1024
#define SIZE 1024*1024
main()
{
char * a;
a = (char *) malloc(ISIZE);
assert(a);
memset(a,0,ISIZE);
printf("Initial size: %d bytes\n",ISIZE);
while (getchar())
{
printf("Allocating %d bytes\n",SIZE);
a = (char *) malloc(SIZE);
assert(a);
memset(a,0,SIZE);
}
}
The machine wasn't too loaded, ( no swapping, active pages ~20% of RAM ).
I let the program ask for memory (pressed a key a certain number of
times), leaving some time though for my process to be almost totally
swapped out (thus ignored by the 'kill the biggest' routine) . After a while,
having reached a '99% swap used' state, everything was locked up (remote
connections, console, etc.), I couldn't event tell which process had been
killed or if something had actually been killed -- we had to reboot :-(
Yet I'm not certain that this is related to a bug in the pageout daemon
...
> > 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.
A least I think that this overcommit behaviour should more documented :-)
> 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)
> dcs@newsguy.com
> dcs@freebsd.org
>
> "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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.95.990922174139.961A-100000>