Date: Wed, 22 Sep 1999 16:29:58 +0200 (MET DST) From: Ivan <Ivan.Djelic@prism.uvsq.fr> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Out of swap handling and X lockups in 3.2R Message-ID: <Pine.SUN.3.95.990922151825.911A-100000@bonnard.prism.uvsq.fr> In-Reply-To: <199909211547.IAA06363@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :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 > <dillon@backplane.com> > 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.990922151825.911A-100000>