Date: Tue, 25 Mar 2003 01:53:01 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Wes Peters <wes@softweyr.com>, John Baldwin <jhb@FreeBSD.ORG> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Patch to protect process from pageout killing Message-ID: <p05200f44baa5a6b76746@[128.113.24.47]> In-Reply-To: <200303242210.32055.wes@softweyr.com> References: <XFMail.20030324140902.jhb@FreeBSD.org> <200303241752.40245.wes@softweyr.com> <p05200f43baa58a1eb364@[128.113.24.47]> <200303242210.32055.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05200f44baa5a6b76746>