Date: Mon, 24 Mar 2003 17:52:40 -0800 From: Wes Peters <wes@softweyr.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Patch to protect process from pageout killing Message-ID: <200303241752.40245.wes@softweyr.com> In-Reply-To: <XFMail.20030324140902.jhb@FreeBSD.org> References: <XFMail.20030324140902.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 24 March 2003 11:09, John Baldwin wrote:
> On 24-Mar-2003 Wes Peters wrote:
> > As promised, here's the patch to protect a process from being
> > killed when pageout is in memory shortage. This allows a process
> > to specify that it is important enough to be skipped when pageout
> > is looking for the largest process to kill.
> >
> > My needs are simple. We make a box that is a web proxy and runs
> > from a memory disk, using flash for permanent storage. The flash
> > is mounted only when a configuration write is needed, the box runs
> > from the memory disk. We've experienced a problem at certain
> > customer sites where bind will consume a lot (~30 MB) of ram and
> > then pageout will kill the largest process, which is usually either
> > named or squid. This pretty much kills the box. We'd much rather
> > have pageout kill off some of the squid worker processes, we can
> > recover from that.
> >
> > Is this a good approach to the problem? Feedback welcome.
>
> I think that adopting the SIGDANGER approach would be better rather
> than rolling our own private interface.
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.
The SIGDANGER interface worries me in general, partly because it's a
signal and partly because it complicates the design of EVERYTHING just
to handle it. I guess a lot depends on the implementation details of
how SIGDANGER and the default handlers are designed, but nothing I saw
last week gave me a warm fuzzy about that.
> > @@ -625,6 +625,15 @@
> > if (limp->rlim_max < 1)
> > limp->rlim_max = 1;
> > break;
> > +
> > + case RLIMIT_PROTECT:
> > + mtx_lock_spin(&sched_lock);
> > + if (limp->rlim_cur)
> > + p->p_flag |= P_PROTECTED;
> > + else
> > + p->p_flag &= ~P_PROTECTED;
> > + mtx_unlock_spin(&sched_lock);
> > + break;
>
> p_flag is protected by PROC_LOCK, not sched_lock.
Gurk! Will fix.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters wes@softweyr.com
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?200303241752.40245.wes>