On Wed, Oct 04, 2017 at 04:46:36PM +0100, Roman Gushchin wrote: > The cgroup-aware OOM killer treats leaf memory cgroups as memory > consumption entities and performs the victim selection by comparing > them based on their memory footprint. Then it kills the biggest task > inside the selected memory cgroup. > > But there are workloads, which are not tolerant to a such behavior. > Killing a random task may leave the workload in a broken state. > > To solve this problem, memory.oom_group knob is introduced. > It will define, whether a memory group should be treated as an > indivisible memory consumer, compared by total memory consumption > with other memory consumers (leaf memory cgroups and other memory > cgroups with memory.oom_group set), and whether all belonging tasks > should be killed if the cgroup is selected. > > If set on memcg A, it means that in case of system-wide OOM or > memcg-wide OOM scoped to A or any ancestor cgroup, all tasks, > belonging to the sub-tree of A will be killed. If OOM event is > scoped to a descendant cgroup (A/B, for example), only tasks in > that cgroup can be affected. OOM killer will never touch any tasks > outside of the scope of the OOM event. > > Also, tasks with oom_score_adj set to -1000 will not be killed. > > The default value is 0. > > Signed-off-by: Roman Gushchin <g...@fb.com> > Cc: Michal Hocko <mho...@kernel.org> > Cc: Vladimir Davydov <vdavydov....@gmail.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > Cc: David Rientjes <rient...@google.com> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Tejun Heo <t...@kernel.org> > Cc: kernel-t...@fb.com > Cc: cgro...@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux...@kvack.org
Those semantics make sense to me and the code looks good. Acked-by: Johannes Weiner <han...@cmpxchg.org> -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
