Re: [patch 18/18] oom: deprecate oom_adj tunable

[David Rientjes <rientjes@google.com>]

On Mon, 21 Jun 2010, KOSAKI Motohiro wrote:

> > Of course it does, it actually has units whereas oom_adj only grows or 
> > shrinks the badness score exponentially.  oom_score_adj's units are well 
> > understood: on a machine with 4G of memory, 250 means we're trying to 
> > prejudice it by 1G of memory so that can be used by other tasks, -250 
> > means other tasks should be prejudiced by 1G in comparison to this task, 
> > etc.  It's actually quite powerful.
> 
> And, no real user want such power.
> 

Google does, and I imagine other users will want to be able to normalize 
each task's memory usage against the others.  It's perfectly legitimate 
for one task to consume 3G while another consumes 1G and want to select 
the 1G task to kill.  Setting the 3G task's oom_score_adj value in this 
case to be -250, for example, depending on the memory capacity of the 
machine, makes much more sense than influencing it as a bitshift on 
top of a vastly unpredictable heuristic with oom_adj.  This seems rather 
trivial to understand.

> When we consider desktop user case, End-users don't use oom_adj by themself.
> their application are using it.  It mean now oom_adj behave as syscall like
> system interface, unlike kernel knob. application developers also don't 
> need oom_score_adj because application developers don't know end-users 
> machine mem size.
> 

I agree, oom_score_adj isn't targeted to the desktop nor is it targeted to 
application developers (unless they are setting it to OOM_SCORE_ADJ_MIN to 
disable oom killing for that task, for example).  It's targeted at 
sysadmins and daemons that partition a machine to run a number of 
concurrent jobs.  It's fine to use memcg, for example, to do such 
partitioning, but memcg can also cause oom conditions with the cgroup.  We 
want to be able to tell the kernel, through an interface such as this, 
that one task shouldn't killed because it's expected to use 3G of memory 
but should be killed when it's using 8G, for example.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>