On Tue, Oct 31, 2017 at 08:04:19AM -0700, Shakeel Butt wrote: > > + > > +static void select_victim_memcg(struct mem_cgroup *root, struct oom_control *oc) > > +{ > > + struct mem_cgroup *iter; > > + > > + oc->chosen_memcg = NULL; > > + oc->chosen_points = 0; > > + > > + /* > > + * The oom_score is calculated for leaf memory cgroups (including > > + * the root memcg). > > + */ > > + rcu_read_lock(); > > + for_each_mem_cgroup_tree(iter, root) { > > + long score; > > + > > + if (memcg_has_children(iter) && iter != root_mem_cgroup) > > + continue; > > + > > Cgroup v2 does not support charge migration between memcgs. So, there > can be intermediate nodes which may contain the major charge of the > processes in their leave descendents. Skipping such intermediate nodes > will kind of protect such processes from oom-killer (lower on the list > to be killed). Is it ok to not handle such scenario? If yes, shouldn't > we document it? Tasks cannot be in intermediate nodes, so the only way you can end up in a situation like this is to start tasks fully, let them fault in their full workingset, then create child groups and move them there. That has attribution problems much wider than the OOM killer: any local limits you would set on a leaf cgroup like this ALSO won't control the memory of its tasks - as it's all sitting in the parent. We created the "no internal competition" rule exactly to prevent this situation. To be consistent with that rule, we might want to disallow the creation of child groups once a cgroup has local memory charges. It's trivial to change the setup sequence to create the leaf cgroup first, then launch the workload from within. Either way, this is nothing specific about the OOM killer. -- 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