From owner-cvs-src Fri Mar 14 13:59:28 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 535A637B401; Fri, 14 Mar 2003 13:59:24 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC49A43FBF; Fri, 14 Mar 2003 13:59:22 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.12.8/8.12.7) with ESMTP id h2ELxLQA003841; Fri, 14 Mar 2003 16:59:21 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20030314152510.A4480@odysseus.silby.com> References: <8023.1047662161@critter.freebsd.dk> <20030314140414.V4480@odysseus.silby.com> <20030314152510.A4480@odysseus.silby.com> Date: Fri, 14 Mar 2003 16:59:20 -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 3:31 PM -0600 3/14/03, Mike Silbersack wrote: >On Fri, 14 Mar 2003, Garance A Drosihn wrote: > >> >In case #2, SIGDANGER wouldn't help much; how much ram can the >> >actively running, legitimate programs really save? > > > > 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"... > >Well, if that's all SIGDANGER did for you, It is better than what FreeBSD presently provides for the same situation. And maybe it sounds lame, but it did in fact work. >then I'd advocate an approach which prioritizes lower uid programs >and/or lower (higher?) nice values. Then lpd _and other important >processes_ would be automatically protected. Again, I do not think we should tie the "willingness to die" to nice-sounding but arbitrary distinctions like this. The fact that I run something as root does not mean that the process has no intelligence about what it could do to help the system when memory is low. This also goes against the desire to have more and more things running as the "regular userid", instead of needing to be root or some other priv userid to run. Or take the case of lpd. There is one process named lpd which must keep running all the time. To empty a print queue, that process forks. It would not be a crisis if a hundred queue- specific processes were to die, but that main process does need to keep running. All the processes are the same userid. They run at the same nice level -- unless you change the source code, but then everyone screams at how undesirable SIGACTION is because you have to change the source code. Almost all of the suggestions that have come forward are good ideas to do *in addition* to SIGDANGER, but SIGDANGER provides a program with a way to SPECIFICALLY address this very SPECIFIC issue, without having to care what UID it got, or what nice value it's willing to run at, or any other unrelated-to-VM actions that it is doing. There is no way that any guessing strategy is going to be better than providing a specific facility which can be used to address a specific issue. Now, most programs won't take advantage of that specific facility, at which point all these other ideas are good ideas for how to make a smarter guess at what best to kill. But if you only rely on a better guessing algorithm, then no matter what algorithm you come up with it is going to "guess wrong". That is fact. And when a frustrated user sees that wrong guess, it would be nice if they had some explicit way to force the "guess" to work out better in their specific situation, for the specific set of processes they are running. Well, I think I've worded this in about as many different ways as I can word it without sounding obnoxious, so I'll give it a rest for awhile. I do think my "modified SIGDANGER idea" is a fairly attractive one (that's the one which includes a way for an administrator to set behavior without recompiling any programs) -- 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