Date: Tue, 29 May 2001 09:06:30 +0300 From: Valentin Nechayev <netch@iv.nn.kiev.ua> To: The Hermit Hacker <scrappy@hub.org> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: machine hangs when no memory/swap left ... Message-ID: <20010529090630.A826@iv.nn.kiev.ua> In-Reply-To: <Pine.BSF.4.33.0105281910040.436-100000@mobile.hub.org>; from scrappy@hub.org on Mon, May 28, 2001 at 07:10:55PM -0300 References: <Pine.BSF.4.33.0105281910040.436-100000@mobile.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mon, May 28, 2001 at 19:10:55, scrappy (The Hermit Hacker) wrote about "machine hangs when no memory/swap left ...": > stupid question, but shouldn't there be a mechanism to prevent that? > something to crash the process or somethign when the machine runs out of > virtual memory? This mechanism exists - let you grep src/sys/vm/vm_pageout.c for killproc() call. But it does not work always. Also it does not work correct in almost any sense. Let's get workstation without any process running, and run on it: 1) top, 2) systat -vm 1, 3) a process which eats all memory and is not limited. When more and more processes swapped, a memory hog more and more sleeps on "vmwait" channel (see src/sys/vm/vm_page.c). When VM exhausts, vm_pageout_scan() kills first not memory hog (which sleeps on "vmwait" channel), but a most fat _running_ process (i.e. top or vmstat). And when top & vmstat are both killed already, then VM kills memory hog. Effect is repeatable (I tested on 5.0-current-20010512). vm_pageout_scan() code tells that it tests both running and sleeping processes, but such stable preference to small running processes is strange. I saw lockups (when system cannot do anything and is totally dead except interrupt handling) estimately 1 per 10 tests. It does not sit in VM scan in this lockup, and I don't know what does it do. How to test what happens during lockup? Due to extremely bad code writing style (no malloc() result checking, and so on) of most target software, I suppose that the only correct reaction for VM exhausting with current software is to reboot system, or at least kill all processes and tell init to restart current runlevel from scratch. This can be do with external or kernel watchdog, but standard realization may be preferred. And pity fact is that VM implementation does not count VM exhausting situations and killed processes. Patch is rather simple. /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010529090630.A826>