Date: Tue, 12 Apr 2005 18:40:50 -0400 From: David Schultz <das@FreeBSD.ORG> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: kernel killing processes when out of swap Message-ID: <20050412224050.GA20005@VARK.MIT.EDU> In-Reply-To: <020201c53f82$e4b54330$b3db87d4@multiplay.co.uk> References: <200504121224.j3CCOFXL019177@marlena.vvi.at> <011a01c53f66$4035aa00$b3db87d4@multiplay.co.uk> <86ll7ox7re.fsf@xps.des.no> <020201c53f82$e4b54330$b3db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 12, 2005, Steven Hartland wrote: > ----- Original Message ----- > >There is no "large process detection". The first process that tries > >to fault in a new page after the system runs out of swap gets killed. > > That makes sense. Me trying to connect to see what was going > on would hence cause sshd to be killed ( not good ). > It would seem that we could do with doing something to prevent this. > We have had a few suggestions so far. > 1. Using madvise, requires code changes per app Using madvise doesn't require changes per app, since MADV_PROTECT is inherited across exec. You just have to write a wrapper, much in the spirit of nice(1), to execute a protected version of X. I agree that it's possible to do better, but this has already been discussed several times before, and whenever it comes up, there's always lots of noise because lots of people who don't understand deadlock chime in. If someone really wants to fix this in a reliable way, they need to go off and implement the necessary accounting in the VM system so that we don't overcommit swap. Most of the other suggestions, such as SIGDANGER, are just heuristics that might save your butt if you're lucky.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050412224050.GA20005>