Re: User space out of memory approach

[Edjard Souza Mota]

Hi,


On Tue, 11 Jan 2005 21:57:49 +0100, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Tue, 2005-01-11 at 16:46 -0400, Ilias Biris wrote:
> > 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 :-)
> >
> > Thinking it in another way alan's email could have the dimension of
> > switching off overcommitment (and thus OOM) whilst in the user-space
> > ranking stage to avoid reentrancy and invocation of oom again and
> > again before killing something. It also solves the issue of using
> > timed/counted resources  which is plain ugly and evil. It would though
> > be necessary to switch OOM back on when the OOMK has finally done the
> > kill.
> >
> > Did I get it right this time Alan?
> 
> I don't get it at all.
> 
> Fixes for wrong invocation, reentrancy avoidance, removal of the ugly
> and evil timer,counter hacks are in the wild since more than 6 weeks.
> They solve the problem without any userspace interaction.
> 
> The userspace provided preferrable victim list is an improvement of the
> generic heuristic and therefor imperfect selection mechanism and nothing
> else.

Once again the user space ranking of PIDs for OOM killer purposes didn't
propose a new selection mechanism. This misinterpretation is misleading the
discussion of whether it may have som use in embedded devices or not.
Even though, I believe that for PCs environment it has a great potential
when you think that admins don't stay all the time in front of a computer.
Once and while they also have a rest :). In these cases, instead of simply
start ranking a deamon could dispatch a msg to her/him saying the system
is approaching a red zone.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/