Re: User space out of memory approach

[Edjard Souza Mota <edjard@gmail.com>]

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?"