Re: User space out of memory approach
From: Edjard Souza Mota (edjard_at_gmail.com)
Date: 01/11/05
- Previous message: Chris Wright: "[PATCH] remove duplicate rlim assignment in acct_stack_growth()"
- In reply to: Thomas Gleixner: "Re: User space out of memory approach"
- Next in thread: Thomas Gleixner: "Re: User space out of memory approach"
- Reply: Thomas Gleixner: "Re: User space out of memory approach"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 11 Jan 2005 04:03:48 +0200 To: tglx@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?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Chris Wright: "[PATCH] remove duplicate rlim assignment in acct_stack_growth()"
- In reply to: Thomas Gleixner: "Re: User space out of memory approach"
- Next in thread: Thomas Gleixner: "Re: User space out of memory approach"
- Reply: Thomas Gleixner: "Re: User space out of memory approach"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
