Re: User space out of memory approach
> > > If my system needs the OOM killer, it's usurally unresponsive to most
> > > userspace applications. A normal daemon would be swapped out before the
> > > runaway dhcpd grows larger than the web cache. It would have to be a
> > > mlocked
> > > RT task started from early userspace. It would be difficult to set up
> > > (unless
> > > you upgrade your distro), and almost nobody will feel like tweaking it to
> > > take the benefit (OOM == -ECANNOTHAPPEN).
> >
> > Please correct me if I got it wrong: as deamon in this case is not a normal
> > one,
> > since it never gets rate for its own safety,
>
> That's it's own task, it must make sure not to commit suicide. I forgot
> about that.
Ok.
> > then it needs an RT lock whenever
> > system boots.
>
> It may not be blocked by a random RT task iff the RT task is supposed to
> be OOM-killed. Therefore it *MUST* run at the highest priority and be
> locked into the RAM.
>
> It *SHOULD* be run at boot time, too, just in case it's needed early.
Yes. That's the idea of the application we posted to test the oom
killer ranking at
user space. At least, we are working to put it at boot time and these
suggestions are very helpful.
> > > 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.
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. The init could be changed to
start the deamon,
and then the module would start controlling it. Am I right?
So that's why people is complaining every distro would have to update the init
and load this new module. Correct?
>
> I 'm thinking of something like that:
>
> [X] support stacking of OOM killer ranking algorhythms
> [X] Task blessing OOM filter
> [X] Userspace OOM ranking daemon
> [X] Default OOM killer ranking
>
> -vs-
>
> [ ] support stacking of OOM killer ranking algorhythms
> ( ) Userspace OOM ranking daemon
> (o) Default OOM killer ranking
>
Very interesting idea. Will take that into account. Thanks a lot.
--
"In a world without fences ... who needs Gates?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: User space out of memory approach
Hi,
> If my system needs the OOM killer, it's usurally unresponsive to most
> userspace applications. A normal daemon would be swapped out before the
> runaway dhcpd grows larger than the web cache. It would have to be a mlocked
> RT task started from early userspace. It would be difficult to set up (unless
> you upgrade your distro), and almost nobody will feel like tweaking it to
> take the benefit (OOM == -ECANNOTHAPPEN).
Please correct me if I got it wrong: as deamon in this case is not a normal one,
since it never gets rate for its own safety, then it needs an RT lock whenever
system boots.
> 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. The way we see the potential for doing
this is that kernel shouldn't worry about users decision on which process to
kill but rather take her/his option into account. The computation of such a
decision could be at user space (protected as you suggested above).
We'll think about it, although I'm not sure if there would be such a decrease
in memory concumption.
br
Edjard
--
"In a world without fences ... who needs Gates?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: User space out of memory approach
Hi, Thanks Alan... > > well looking into Alan's email again I think I answered thinking on > > the wrong side :-) that the suggestion was to switch off OOM > > altogether and be done with all the discussion... tsk tsk tsk too > > defensive and hasty I guess :-) > > Thats what mode 2 is all about. There are some problems with over-early > triggering of OOM that Andrea fixed that are still relevant (or stick > "never OOM if mode == 2" into your kernel) > > > Did I get it right this time Alan? > > Basically yes - the real problem with the OOM situation is there is no > correct answer. People have spent years screwing around with the OOM > killer selection logic and while you can make it pick large tasks or old > tasks or growing tasks easily nobody has a good heuristic about what to > die because it depends on the users wishes. OOM requires AF_TELEPATHY > sockets and we don't have them. > > > For most users simply not allowing the mess to occur solves the problem > - not all but most. > What do you think about the point we are trying to make, i.e., moving the ranking of PIDs to be killed to user space? Or, making user have some influence on it? We were misunderstood because the patch we sent was to make "a slight" organization in the way OOM killer compute rates to PIDs, not to change its selection logic. But now, we can discuss (I mean implement) alternative selection logics without messing the code at kernel space. The parameters and criteria on how to combine them can be open to more people test it according to platform and, if not user, at least according to application memory consumpition pattern. Well, while AF_TELEPATH socket is not on its way :) ... we may at least experiment different raking policies. br Edard -- "In a world without fences ... who needs Gates?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
