Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c

[ Available lists | Index of cvs-src | Month of Mar 2003 | Week of 14 Mar 2003 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Juli Mallett <jmallett@FreeBSD.org>
Date
14 Mar 2003 08:19:00
Subject
Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c
Message-ID
20030314101857.A98861@FreeBSD.org


[ Hide this part ]
* De: Eivind Eklund <eivind@FreeBSD.org> [ Data: 2003-03-14 ]
[ Subjecte: Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c ]
> On Thu, Mar 13, 2003 at 03:46:22PM -0600, Mike Silbersack wrote:
> > > I believe Juli is working on a
> > > way to designate certain processes as unkillable by the pageout
> > > daemon, so people running postgres on a busy system, for instance,
> > > are not unpleasantly surprised when the pageout daemon runs out of
> > > breathing room and decides that postmaster is the biggest process.
> >
> > That could be useful, although I think it may be more trouble that it's
> > worth. (Why give shell accounts on the postgres machine?)
>
> Having had as my workstation a FreeBSD machine with X, netscape, and too
> little RAM, I think it would be very useful for some situations. You have
> no idea how annoying it is when netscape eats all your memory and FreeBSD
> decide that the solution to this is to kill *X*.

I've had that happen for me (though the combinations required are a lot
lower, as my RAM is a lot lower :>), and that's why I started looking into
this. I didn't realise my name had been dragged into this until just now :)

Basically I was adding a new signal, SIGVM (or SIGNOMEM), and the semantics
were as such:
1) If a process has SIG_IGN for the signal set, it is skipped over
when looking for a process to kill.
2) If a process has SIG_DFL for the signal set, it is "killable,"
in that it is willing to die.
3) If a process has a handler for the signal set, that handler is
invoked*.

* - Note that I've waffled about that quite a bit. I think that we'd want
libc to maybe default to letting phkmalloc try to shrink the break area,
or get rid of some spare buffers. All the obvious things like that. And
we would want to expose an interface to do it, for people who want to do
something small and then let libc cleanup. There are a lot of ways you
could do this... On IRC, das talked about thinking signals were a bad idea
for this, and wanting to add something to flick a bit and mark a process as
killable or unkillable. I think that could work, too. In fact, a general
purpose bit-flipper of process flags that are runtime tunable would be nice.

Of course, you want to kill a "few" SIG_DFL processes, and activate a "few"
handler processes, to make sure you can do something to free up some room.
Probably want to have the OOM killer start working *with a small amount of
room to spare* which is enough to do swapin/swapout, and send signals. That
would be something you'd want tunable, and relative to "few" above.

Those are my thoughts, I'm not working on it right now, per se, so if someone
else likes the idea of doing such, they should go for it.

Thanx,
juli.
--
juli mallett. email: jmallett@freebsd.org; aim: bsdflata; efnet: juli;

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-src" in the body of the message



Elapsed time: 0.199 seconds