From owner-freebsd-hackers Wed Jul 14 17: 7:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 591F81501F; Wed, 14 Jul 1999 17:07:02 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-2.bellatlantic.net [151.198.135.2]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA05043; Wed, 14 Jul 1999 20:05:46 -0400 (EDT) Message-ID: <378D2682.DA0D38A0@bellatlantic.net> Date: Wed, 14 Jul 1999 20:08:34 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: Garance A Drosihn Cc: "Daniel C. Sobral" , Matthew Dillon , "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: > > In which case the program that consumed all memory will be killed. > > The program killed is +NOT+ the one demanding memory, it's the one > > with most of it. > > But that isn't always the best process to have killed off... > > One of my main freebsd machines is mainly here to run one > process, which is a pretty good-sized process (>40meg). If > I did get into a memory-shortage problem, I do *not* want > that process killed, I'd want some other processes killed. > > It would be nice to have a way to indicate that, a la SIGDANGER. Another option may be to add something like "importance classes". Suppose we assign an one-byte "importance level" to each process. When we get out of swap we start killing processes with the lowest importance level. This seems to be both easy to implement and a rather robust solution. It can be extended to more flexible policies: say, we divide this 8-bit number into two 4-bit fields. The high field will be "major importance level" the low field will be "importance sublevel". We permit the user processes to change their sublevel to any value as long their major level stays the same or becomes lower. This will allow the users to make differences between their programs but only in certain limits. The initial importance level may be set in /etc/login.conf. One more extension would be to use one bit as the ihneritance flag: if it is set, the child inherits the importance value from the parent. But if it's reset the child inherits its major level from the parent but the sublevel gets reset to 0. It may be useful for transparent calls of system(). Yet another extension would be to use two separate inheritance bits: one as described above, the secone one if reset means that the importance value of the child must be reset to the lowest one. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message