[lkml]   [2017]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [v6 2/4] mm, oom: cgroup-aware OOM killer
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.

 \ /
  Last update: 2017-08-24 01:19    [W:0.227 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site