Re: User space out of memory approach

[Bodo Eggert <7eggert@gmx.de>]

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