Re: [patch -mm 1/2] oom: badness heuristic rewrite

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Mon, 2 Aug 2010 17:27:13 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> On Tue, 3 Aug 2010, KAMEZAWA Hiroyuki wrote:
> 
> > One reason I poitned out is that this new parameter is hard to use for admins and
> > library writers. 
> >   old oom_adj was defined as an parameter works as 
> > 		(memory usage of app)/oom_adj.
> 
> Where are you getting this definition from?
> 
> Disregarding all the other small adjustments in the old heuristic, a 
> reduced version of the formula was mm->total_vm << oom_adj.  It's a 
> shift, not a divide.  That has no sensible meaning.
> 
yes. that was quite useless.



> >   new oom_score_adj was define as
> > 		(memory usage of app * oom_score_adj)/ system_memory
> > 
> 
> No, it's (rss + swap + oom_score_adj) / bound memory.  It's an addition, 
> not a multiplication, and it's a proportion of memory the application is 
> bound to, not the entire system (it could be constrained by cpuset, 
> mempolicy, or memcg).
> 
sorry.

> > Then, an applications' oom_score on a host is quite different from on the other
> > host. This operation is very new rather than a simple interface updates.
> > This opinion was rejected.
> > 
> 
> It wasn't rejected, I responded to your comment and you never wrote back.  
> The idea 
> 
I just got tired to write the same thing in many times. And I don't have
strong opinions. I _know_ your patch fixes X-server problem. That was enough
for me.


> > Anyway, I believe the value other than OOM_DISABLE is useless,
> 
> You're right in that OOM_DISABLE fulfills may typical use cases to simply 
> protect a task by making it immune to the oom killer.  But there are other 
> use cases for the oom killer that you're perhaps not using where a 
> sensible userspace tunable does make a difference: the goal of the 
> heuristic is always to kill the task consuming the most amount of memory 
> to avoid killing tons of applications for subsequent page allocations.  We 
> do run important tasks that consume lots of memory, though, and the kernel 
> can't possibly know about that importance.  So although you may never use 
> a positive oom_score_adj, although others will, you probably can find a 
> use case for subtracting a memory quantity from a known memory hogging 
> task that you consider to be vital in an effort to disregard that quantity 
> from the score.  I'm sure you'll agree it's a much more powerful (and 
> fine-grained) interface than oom_adj.
> 
Yes, I agree if we can assume the admins are very clever.

> > I have no concerns. I'll use memcg if I want to control this kind of things.
> > 
> 
> That would work if you want to setup individual memcgs for every 
> application on your system, know what sane limits are for each one, and 
> want to incur the significant memory expense of enabling 
> CONFIG_CGROUP_MEM_RES_CTLR for its metadata.
> 
Usual disto alreay enables it.

Simply puts all applications to a group and disable oom and set oom_notifier. 
Then,
 - a "pop-up window" of task list will ask the user "which one do you want to kill ?"
 - send a packet to ask a administlation server system "which one is killable ?"
   or "increase memory limit" or "memory hot-add ?" 

Possible case will be
   - send SIGSTOP to all apps at OOM.
   - rise limit to some extent. or move a killable one to a special group.
   - wake up a killable one with SIGCONT.
   - send SIGHUP to stop it safely.

"My application is killed by the system!!, without running safe emeregency code!"
is the fundamental seeds of disconent.


Thanks,
-Kame


--
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>