From owner-freebsd-hackers Wed Sep 22 9:22:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by hub.freebsd.org (Postfix) with ESMTP id 3A6EB14DDB for ; Wed, 22 Sep 1999 09:22:34 -0700 (PDT) (envelope-from Ivan.Djelic@prism.uvsq.fr) Received: from lucifer.prism.uvsq.fr (lucifer.prism.uvsq.fr [193.51.25.7]) by soleil.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA96391 ; Wed, 22 Sep 1999 18:22:24 +0200 (CEST) Received: from bonnard.prism.uvsq.fr (bonnard.prism.uvsq.fr [193.51.25.81]) by lucifer.prism.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id SAA06987 ; Wed, 22 Sep 1999 18:22:24 +0200 (MET DST) Received: from localhost (djelic@localhost) by bonnard.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id SAA00974 ; Wed, 22 Sep 1999 18:22:18 +0200 (MET DST) Date: Wed, 22 Sep 1999 18:22:17 +0200 (MET DST) From: Ivan To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R In-Reply-To: <37E8F645.7437D0D9@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 #include #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