From owner-freebsd-arch Mon Mar 24 22:53:10 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E81AF37B401; Mon, 24 Mar 2003 22:53:04 -0800 (PST) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D72E43F93; Mon, 24 Mar 2003 22:53:04 -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 h2P6r2QA023930; Tue, 25 Mar 2003 01:53:02 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200303242210.32055.wes@softweyr.com> References: <200303241752.40245.wes@softweyr.com> <200303242210.32055.wes@softweyr.com> Date: Tue, 25 Mar 2003 01:53:01 -0500 To: Wes Peters , John Baldwin From: Garance A Drosihn Subject: Re: Patch to protect process from pageout killing Cc: freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 X-Spam-Status: No, hits=-25.9 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:10 PM -0800 3/24/03, Wes Peters wrote: >On Monday 24 March 2003 20:53, Garance A Drosihn wrote: >> At 5:52 PM -0800 3/24/03, Wes Peters wrote: >> > >> >It's not clear to me the SIGDANGER interface allows me to say >> >"go elsewhere bub, I'm really important." In this case, that >> >is essential. I think even in the general FreeBSD case you can >> >make a point for a setting like this in, say, named. >> >> Please check out the descriptions I posted previously. SIGDANGER >> (as implemented by AIX) explicitly provides two things. The process >> gets to decide which one they (the process) wants: >> >> 1) signal me at the first sign of trouble, and I'll free >> up some virtual memory (possibly by exit()-ing). >> 2) do not ever kill me to free up memory. > >The current situation, leave me alone until you're really hurting, >then just kill me quickly, should not only be an option but be the >default. Is that covered? As the default? I.e. if I don't >specify any handling of SIGDANGER at all, does it continue to >work as now? Yes. >I guess my biggest worry about SIGDANGER is that minds much brighter >than yours or mine share my worries about it. Relying on signal >delivery is just not in my nature. Actually, I think the biggest complaint with SIGDANGER (as AIX does it), is that you *must* recompile programs to add the signal-handler, or SIGDANGER does you absolutely no good. This leads to the argument "what if I don't have the source to some program that should not be killed?". Or, for that matter, "what if I don't have the source to a program which I know should be among the first to die?" This is an area where I think we could do better than the AIX implementation, although "doing better" does imply "more work"... I think we want to come up with something so people don't have to go changing every program to add a signal handler, but the decision would usually be left to the system-admin. > > I don't know enough about the lower-level implementation details, >> but I did think the recent discussion on the src-committers list >> did include a number of good ideas. I am horribly over-committed >> with things that I've promised to do (including stuff for my real- >> world job...), so I can't look into SIGDANGER ideas right now, but >> I'm more than happy to try to explain how it should work. > >Some of the explanations were reasonable enough to erase all of my >objections EXCEPT "it's a signal." Do we have signal delivery to >multi-threaded processes worked out enough to rely on SIGDANGER >for such a critical function? If so, it's news to me, but that >doesn't mean it's not done... Well, most signal handlers for SIGDANGER are very simple, so they should tend to work even if signal-handling in general is iffy. They either: static void ignore_danger(int signo) { /* Just return, thus telling the kernel "Do Not Kill Me" */ } or static void we_are_really_nice(int signo) { /* System is running out of VM -- so we will disappear! */ exit(1); } Well, those are the two kinds I have written. I guess the second one could be a lot more complicated. Really it should set a flag and then let some other main-processing-loop do the exit() call. I don't know what that means for multi-threaded programs under freebsd, but since you don't *have* to add a signal-handler to every program, it might be that most system administrators will be able to solve their low-memory issues even if signal-handling did not work reliably for all 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 freebsd-arch" in the body of the message