From owner-cvs-src Fri Mar 14 13: 6: 5 2003 Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1D7037B401; Fri, 14 Mar 2003 13:06:01 -0800 (PST) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 378D943F93; Fri, 14 Mar 2003 13:05:58 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2EL5uBg018277; Fri, 14 Mar 2003 16:05:56 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030314140414.V4480@odysseus.silby.com> References: <8023.1047662161@critter.freebsd.dk> <20030314140414.V4480@odysseus.silby.com> Date: Fri, 14 Mar 2003 16:05:55 -0500 To: Mike Silbersack From: Garance A Drosihn Subject: Re: cvs commit: src/sys/vm ... SIGDANGER Cc: Poul-Henning Kamp , "Daniel C. Sobral" , Juli Mallett , Eivind Eklund , David Schultz , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 Sender: owner-cvs-src@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:15 PM -0600 3/14/03, Mike Silbersack wrote: >On Fri, 14 Mar 2003, Garance A Drosihn wrote: > >> The web page I gave in my other message also talks about a >> 'psdanger' routine, which sounds like it might be what you're >> talking about. >> >> [of course, as a userland-type-of-programmer, I'm hoping some >> kernel-type will get excited about the idea and implement the > > same set of ideas for FreeBSD. :-)] > >I'm really not sure how much of a help this SIGDANGER or whatever >will be. As I see it, there are two cases of OOM: > >1. Heavy load, lots of busy processes, all legitimate. > - Nobody has complained about this case having problems. > >2. Light load, then some program goes crazy and forks / chews > up ram. X gets killed. > - I think this is what people are complaining about. > >In case #2, SIGDANGER wouldn't help much; how much ram can the >actively running, legitimate programs really save? Uh, in case #2, you would change X to have a SIGDANGER signal-handler, and have that signal-handler simply "Do Nothing" and return. Thus, the mere presence of the signal-handler will make sure that X is never the thing that gets killed. The SIGDANGER signal-handler that I added to 'lpd' (at RPI) has the name "ignore_danger"... Note that I had first-hand experience with this very scenario, and I found that SIGDANGER (as implemented in AIX) *did* let me do what I needed to do. And the only program I changed was 'lpd'. I didn't have to track down every student on the RPI campus and tell them to "behave", or to "please do not write fork-bombs while doing your systems-programming project", either of which would be a hopeless proposition. It is definitely a help. It is definitely better than the nothing that FreeBSD currently provides. If FreeBSD also had a psdanger routine, for programs which *do* want to monitor the swapping-situation, that would benefit a different set of situations. Taken together, it'd be a very nice step forward. >What might be a good solution is to use some sort of statistics >basic heuristic when determining what to kill. The SIGDANGER strategy is proven to work, and it should be much easier to implement. SIGDANGER is also attractive in that anyone who is already using SIGDANGER for AIX would then benefit when moving to FreeBSD, and any program using it on FreeBSD would then have it if some unfortunate soul had to port the program to AIX. Add sysctl's to set the two threshold levels, and the admin would even have a way to tune the behavior (well, a little). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-src" in the body of the message