Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2003 10:18:57 -0600
From:      Juli Mallett <jmallett@FreeBSD.org>
To:        Eivind Eklund <eivind@FreeBSD.org>
Cc:        Mike Silbersack <silby@silby.com>, David Schultz <das@FreeBSD.org>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/vm vm_map.c vm_map.h vm_pageout.c
Message-ID:  <20030314101857.A98861@FreeBSD.org>
In-Reply-To: <20030314012954.A42430@FreeBSD.org>; from eivind@FreeBSD.org on Fri, Mar 14, 2003 at 01:29:54AM -0800
References:  <200303122313.h2CNDHMU046431@repoman.freebsd.org> <20030312175458.J32334@odysseus.silby.com> <20030313005115.GA11794@HAL9000.homeunix.com> <20030313154226.X682@odysseus.silby.com> <20030314012954.A42430@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
* 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-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030314101857.A98861>