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. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
