[lkml]   [2010]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Improving OOM killer
On Wed, 3 Feb 2010, KOSAKI Motohiro wrote:

> Personally, I think your use case represent to typical desktop and Linux
> have to works fine on typical desktop use-case. /proc/pid/oom_adj never fit
> desktop use-case. In past discussion, I'v agreed with much people. but I haven't
> reach to agree with David Rientjes about this topic.

Which point don't you agree with? I've agreed that heuristic needs to be
changed and since Kame has decided to abandon his oom killer work, I said
that I would find time to develop a solution that would be based on
consensus. I don't think that simply replacing the baseline with rss,
rendering oom_adj practically useless for any other purpose other than
polarizing priorities, and removing any penalty for tasks that fork an
egregious amount of tasks is acceptable to all parties, though.

When a desktop system runs a vital task that, at all costs, cannot
possibly be oom killed such as KDE from the user perspective, is it really
that outrageous of a request to set it to OOM_DISABLE? No, it's not.
There are plenty of open source examples of applications that tune their
own oom_adj values for that reason; userspace input into the oom killer's
heuristic will always be an integral part of its function.

I believe that we can reach consensus without losing the existing
functionality that oom_adj provides, namely defining vital system tasks
and memory leakers, and without this all or nothing type attitude that
insists we either go with rss as a baseline because "it doesn't select X
first in my particular example" or you'll just take your ball and go home.

 \ /
  Last update: 2010-02-03 10:43    [W:0.129 / U:1.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site