Re: [PATCH] mm, memcg: introduce per memcg oom_score_adj

[Michal Hocko <mhocko@suse.com>]

On Thu 22-08-19 04:56:29, Yafang Shao wrote:
> - Why we need a per memcg oom_score_adj setting ?
> This is easy to deploy and very convenient for container.
> When we use container, we always treat memcg as a whole, if we have a per
> memcg oom_score_adj setting we don't need to set it process by process.

Why cannot an initial process in the cgroup set the oom_score_adj and
other processes just inherit it from there? This sounds trivial to do
with a startup script.

> It will make the user exhausted to set it to all processes in a memcg.

Then let's have scripts to set it as they are less prone to exhaustion
;)
But seriously

> In this patch, a file named memory.oom.score_adj is introduced.
> The valid value of it is from -1000 to +1000, which is same with
> process-level oom_score_adj.
> When OOM is invoked, the effective oom_score_adj is as bellow,
>     effective oom_score_adj = original oom_score_adj + memory.oom.score_adj

This doesn't make any sense to me. Say that process has oom_score_adj
-1000 (never kill) then group oom_score_adj will simply break the
expectation and the task becomes killable for any value but -1000.
Why is summing up those values even sensible?

> The valid effective value is also from -1000 to +1000.
> This is something like a hook to re-calculate the oom_score_adj.

Besides that. What is the hierarchical semantic? Say you have hierarchy
	A (oom_score_adj = 1000)
	 \
	  B (oom_score_adj = 500)
	   \
	    C (oom_score_adj = -1000)

put the above summing up aside for now and just focus on the memcg
adjusting?
-- 
Michal Hocko
SUSE Labs