Date: Thu, 23 Sep 1999 00:31:17 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Ivan <Ivan.Djelic@prism.uvsq.fr> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R Message-ID: <37E8F645.7437D0D9@newsguy.com> References: <Pine.SUN.3.95.990922151825.911A-100000@bonnard.prism.uvsq.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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) 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?37E8F645.7437D0D9>