From owner-freebsd-hackers Tue Apr 28 02:46:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA07862 for freebsd-hackers-outgoing; Tue, 28 Apr 1998 02:46:40 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail1.its.rpi.edu (root@mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA07853 for ; Tue, 28 Apr 1998 02:46:36 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id FAA60028 for ; Tue, 28 Apr 1998 05:46:35 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@pop1.rpi.edu Message-Id: In-Reply-To: References: Date: Tue, 28 Apr 1998 05:49:56 -0400 To: freebsd-hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: SIGDANGER Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:32 PM -0400 4/27/98, Adrian T. Filipi-Martin wrote: >On Mon, 27 Apr 1998, David E. Cross wrote: > >> I was recently shown AIX's SIGDANGER (33). It is a signal that the kernel >> issues to [some] running processes when it gets dangerously low on space, >> by default SIGDANGER causes programs to die, freeing up memory, system >> critical processes and server processes would be compiled to ignore >> SIGDANGER. This seems like a very good idea, could it be done in >> FreeBSD? > > I always thought SIGDANGER was considered the worst of all bad > ideas. It greatly reduces determinism because when you over allocate > memory and then discover that you are short on memory the process that > is SIGDANGERED is randomly chosen randomly from the offending process > group. It may not even be a process that improves the situation when > dead. If you have a system which does overallocate, you're going to randomly pick processes to kill. Or maybe the system will even make a pretty good guess at what to kill. That is a true statement with or without SIGDANGER. The question is, will there be any way for some critical process (system daemons, the X-server, whatever) to tell the system "No, don't kill me, try to kill someone else first!". The example you give isn't particularly interesting, as I (as a system administrator) don't really care if any or all of those pittly little processes ( :-) ) get killed. I may, however, be very unhappy if sshd or the main lpd process gets killed just because they *happen* to be the process which requests memory at the wrong time while you're running that "danger.c" program. - - - Of course, the next question is how this should work. I don't know enough about AIX, but when I went to add this in a program of mine, the first thing I thought of was "okay, great, now how do I tell whether my signal-handler is doing the right thing?". Sure, I could send it a sigdanger, but that wouldn't cause it to be called while the system really is low on memory. And if I run my own danger.c program to force a (test) system to be low on memory, how do I make sure the system will try to kill the program I'm testing? So, if SIGDANGER support is added to FreeBSD, it may also be amusing if a process could tell the kernel "try to kill me first, if you're every running out of memory". Really I want that for testing, but now that I think of it, that option might be useful in real-life programs too. Say I'm running some real-world background job that I don't really care about (such as the recent DESchall client, or any similar "idle cycle" program). If the machine is running out of memory, I'd want to see that client die first, because I *know* nothing depends on it... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message