From owner-freebsd-hackers Wed Sep 22 7:30:48 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 4299C14FD9 for ; Wed, 22 Sep 1999 07:30:23 -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 QAA86484 ; Wed, 22 Sep 1999 16:30:08 +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 QAA02393 ; Wed, 22 Sep 1999 16:30:06 +0200 (MET DST) Received: from localhost (djelic@localhost) by bonnard.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id QAA00934 ; Wed, 22 Sep 1999 16:29:59 +0200 (MET DST) Date: Wed, 22 Sep 1999 16:29:58 +0200 (MET DST) From: Ivan To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R In-Reply-To: <199909211547.IAA06363@apollo.backplane.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 > :where SIZE was 4 MB in this case. I ran it on the console (I've got 64 MB > :of RAM and 128 MB of swap) until the swap pager went out of space and > :my huge process was eventually killed as expected. Fine. But when I ran > :it under X Window, the system eventually killed the X server (SIZE ~20 MB, > :RES ~14 MB -- the biggest RES size) instead of my big process (SIZE ~100 > :MB, RES 0K). > : > :My question is: Why was the X server killed ? Was it because the 'biggest' > :process is the one with the biggest resident memory size ? > :And if so, why not take into account the total size of processes ? > > The algorithm is pretty dumb. In fact, it would not be too difficult > to actually calculate the amount of swap being used by a process and > add that to the RSS when figuring out who to kill. Thank you for your explanations ! 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 ) . 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 ? > > The X server wasn't killed nicely, it couldn't take you out of the > video mode. > 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 ? 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 !?) Is this a currently addressed issue, or is it simply considered not an issue ? Thanks in advance for your time, Ivan > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message