Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262052AbVATFBi (ORCPT ); Thu, 20 Jan 2005 00:01:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262051AbVATFBh (ORCPT ); Thu, 20 Jan 2005 00:01:37 -0500 Received: from mail-in-07.arcor-online.net ([151.189.21.47]:34970 "EHLO mail-in-07.arcor-online.net") by vger.kernel.org with ESMTP id S262052AbVATFA6 convert rfc822-to-8bit (ORCPT ); Thu, 20 Jan 2005 00:00:58 -0500 Date: Thu, 20 Jan 2005 06:00:54 +0100 (CET) From: Bodo Eggert <7eggert@gmx.de> To: Edjard Souza Mota Cc: Bodo Eggert <7eggert@gmx.de>, Alan Cox , Ilias Biris , Linux Kernel Mailing List Subject: Re: User space out of memory approach In-Reply-To: <4d6522b90501191920410780fe@mail.gmail.com> Message-ID: References: <4d6522b905011805154bf27b52@mail.gmail.com> <4d6522b90501191920410780fe@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3455 Lines: 79 On Thu, 20 Jan 2005, Edjard Souza Mota wrote: > > > > What about creating a linked list of (stackable) algorhithms which can be > > > > extended by loading modules and resorted using {proc,sys}fs? It will avoid > > > > the extra process, the extra CPU time (and task switches) to frequently > > > > update the list and I think it will decrease the typical amount of used > > > > memory, too. > > > > > > Wouldn't this bring the (set of ) ranking algorithm(s) back to the kernel? This > > > is exactly what we're trying to avoid. > > > > You're trying to avoid it in order to let admins try other ranking > > algorhithms (at least that's what I read). The module approach seems to be > > flexible enough to do that, and it avoids the mentioned issues. If you > > really want a userspace daemon, it can be controled by a module.-) > > Yes, your reading is correct, but this choice should take into account > the "patterns" > of how memory is allocated for user's mostly used applications. Why? > The closer the > ranking gets to "The Best choice" the longer it will take to invoke > oom killer again. ACK. > I am wondering how could a module control a user space deamon if it > hasn't started > yet? I mean, processes at user space are supposed to start only after > all modules > are loaded (those loadable at boot time). So, this user space deamon > would break > this standard. But if we manage to have a special module that takes > care of loading > this stack of OOM Killer ranking algorithms, then the deamon would > not need to break > the default order of loading modules. I don't think there neeeds to be a special order while loading the modules, since each module will provide a defined interface which can be registered in a linked list and sorted on demand. Just init all compiled-in modules and sort using a kernel-parameter (remembering modprobe might be fubar), then modprobe (if compiled-in) all missing decision modules from the list (appending them) and resort again. If the admin wants to add a module later, he can also change the order again, possibly after configuring the module. Disabeling may be either done by moving a decision past one without fall-through or by using a seperate list. There will be a need for a controling instance which will build a list of candidates and pass it to each decision module in turn untill the victim is found. Maybe the list will need a field for a ranking offset and a scaling factor if a module is not supposed to do the final decision but to modify the ranking for some blessed processes. > The init could be changed to > start the deamon, > and then the module would start controlling it. Am I right? It can, but it should be run from the (possibly autogenerated) initr{d,amfs} if it's used. > So that's why people is complaining every distro would have to update the init > and load this new module. Correct? ACK. (It's just me - for now) Upgrading kernels used to be a drop-in replacement, except for ISDN and (for 2.4 -> 2.6) v4l. I like it that way. -- Top 100 things you don't want the sysadmin to say: 66. What do you mean you needed that directory? Fri?, Spammer: nI4m@egiefdjm.info technik@gueb.de order@upstair.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/