Re: User space out of memory approach

From: Bodo Eggert
Date: Thu Jan 20 2005 - 00:03:31 EST


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@xxxxxxxxxxxxx technik@xxxxxxx order@xxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/