[lkml]   [2018]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch v3 -mm 3/6] mm, memcg: add hierarchical usage oom policy
On Mon, 16 Jul 2018, Roman Gushchin wrote:

> Hello, David!
> I think that there is an inconsistency in the memory.oom_policy definition.
> "none" and "cgroup" policies defining how the OOM scoped to this particular
> memory cgroup (or system, if set on root) is handled. And all sub-tree
> settings do not matter at all, right? Also, if a memory cgroup has no
> memory.max set, there is no meaning in setting memory.oom_policy.

Hi Roman,

The effective oom policy is based on the mem cgroup that is oom. That can
occur when memory.max is set, yes.

If a mem cgroup does not become oom itself, its oom policy doesn't do
anything until, well, it's oom :)

> And "tree" is different. It actually changes how the selection algorithm works,
> and sub-tree settings do matter in this case.

"Tree" is considering the entity as a single indivisible memory consumer,
it is compared with siblings based on its hierarhical usage. It has
cgroup oom policy.

It would be possible to separate this out, if you'd prefer, to account
an intermediate cgroup as the largest descendant or the sum of all
descendants. I hadn't found a usecase for that, however, but it doesn't
mean there isn't one. If you'd like, I can introduce another tunable.

 \ /
  Last update: 2018-07-17 06:07    [W:0.122 / U:0.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site