From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751671AbdHWXTQ (ORCPT ); Wed, 23 Aug 2017 19:19:16 -0400 Received: from mail-pg0-f53.google.com ([74.125.83.53]:36995 "EHLO mail-pg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751613AbdHWXTN (ORCPT ); Wed, 23 Aug 2017 19:19:13 -0400 X-Google-Smtp-Source: ADKCNb52Yt8feeyfzI2UBz4eHOswX6P93pUsI9+xqAVCAgYXAS5RbUN5rWbog9DUie+ua1N2UJRmnA== Date: Wed, 23 Aug 2017 16:19:11 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Roman Gushchin cc: linux-mm@kvack.org, Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , Tejun Heo , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v6 2/4] mm, oom: cgroup-aware OOM killer In-Reply-To: <20170823165201.24086-3-guro@fb.com> Message-ID: References: <20170823165201.24086-1-guro@fb.com> <20170823165201.24086-3-guro@fb.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Aug 2017, Roman Gushchin wrote: > Traditionally, the OOM killer is operating on a process level. > Under oom conditions, it finds a process with the highest oom score > and kills it. > > This behavior doesn't suit well the system with many running > containers: > > 1) There is no fairness between containers. A small container with > few large processes will be chosen over a large one with huge > number of small processes. > > 2) Containers often do not expect that some random process inside > will be killed. In many cases much safer behavior is to kill > all tasks in the container. Traditionally, this was implemented > in userspace, but doing it in the kernel has some advantages, > especially in a case of a system-wide OOM. > > 3) Per-process oom_score_adj affects global OOM, so it's a breache > in the isolation. > > To address these issues, cgroup-aware OOM killer is introduced. > > Under OOM conditions, it tries to find the biggest memory consumer, > and free memory by killing corresponding task(s). The difference > the "traditional" OOM killer is that it can treat memory cgroups > as memory consumers as well as single processes. > > By default, it will look for the biggest leaf cgroup, and kill > the largest task inside. > > But a user can change this behavior by enabling the per-cgroup > oom_kill_all_tasks option. If set, it causes the OOM killer treat > the whole cgroup as an indivisible memory consumer. In case if it's > selected as on OOM victim, all belonging tasks will be killed. > I'm very happy with the rest of the patchset, but I feel that I must renew my objection to memory.oom_kill_all_tasks being able to override the setting of the admin of setting a process to be oom disabled. From my perspective, setting memory.oom_kill_all_tasks with an oom disabled process attached that now becomes killable either (1) overrides the CAP_SYS_RESOURCE oom disabled setting or (2) is lazy and doesn't modify /proc/pid/oom_score_adj itself. I'm not sure what is objectionable about allowing memory.oom_kill_all_tasks to coexist with oom disabled processes. Just kill everything else so that the oom disabled process can report the oom condition after notification, restart the task, etc. If it's problematic, then whomever is declaring everything must be killed shall also modify /proc/pid/oom_score_adj of oom disabled processes. If it doesn't have permission to change that, then I think there's a much larger concern. > Tasks in the root cgroup are treated as independent memory consumers, > and are compared with other memory consumers (e.g. leaf cgroups). > The root cgroup doesn't support the oom_kill_all_tasks feature.