Re: User space out of memory approach

From: Edjard Souza Mota <edjard@gmail.com>
To: tglx@linutronix.de
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
	Mauricio Lin <mauriciolin@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Andrea Arcangeli <andrea@suse.de>
Subject: Re: User space out of memory approach
Date: Tue, 11 Jan 2005 04:03:48 +0200	[thread overview]
Message-ID: <4d6522b90501101803523eea79@mail.gmail.com> (raw)
In-Reply-To: <1105403747.17853.48.camel@tglx.tec.linutronix.de>

Some points on Thomas comments,

> 
> I have no objections against the userspace provided candidate list
> option, but as long as the main sources of trouble
> 
>         - invocation
>         - reentrancy
>         - timed, counted, blah ugly protection
>         - selection problem
> 
> are not fixed properly, we don't need to discuss the inclusion of a
> userspace provided candidate list.

Any solution that doesn't  offer a proper approach to the above issues
should not be discussed anyway. By allowing the ranking goes up to the
user space is not meant only for user testing ranking, but to keep the
OOM Killer kernel code simpler and clean. As a matter of fact, even
protected.

Consider the invocation for example. It comes in two phases with this proposal:
1) ranking for the most likely culprits only starts when memory consumption
    gets close to the red zone (for example 98% or something like that).
2) killing just gets the first candidate from the list and kills it.
No need to calculate
    at kernel level.

The selection problem is very dependent on the ranking algorithm. For PCs it
may not be a trouble, but for emdedded devices? yes it is. The ranking at the
kernel level uses only int type of integer. If you get the log file
for the ranking
in any embedded device you will notice that many processes end up with
the same ranking point. Thus, there will never be the best choice in this way.

By moving just the ranking to the user space fix this problem 'cause you may
use float to order PIDs with different indexes. The good side effect is that we 
allow better ways of choosing the culprit by means of diffrent calculations to 
meet different patterns of memory consumtion.

> Postpone this until the main problem is fixed. There is a proper
> confirmed fix for this available. It was posted more than once.
> 
> Merging a fix which helps only 0,001 % of the users to hide the mess
> instead of fixing the real problem is a real interesting engineering
> aproach.
> 
> I don't deny, that after the source of trouble is fixed it is worth to
> think about the merging of this addon to allow interested users to
> define the culprits instead of relying on an always imperfect selection
> algorithm.

br

Edjard
-- 
"In a world without fences ... who needs Gates?"