[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200319133746.GA187654@cmpxchg.org>
Date: Thu, 19 Mar 2020 09:37:46 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Roman Gushchin <guro@...com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org,
kernel-team@...com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: memcg: make memory.oom.group tolerable to task
migration
On Mon, Mar 16, 2020 at 03:35:10PM -0700, Roman Gushchin wrote:
> If a task is getting moved out of the OOMing cgroup, it might
> result in unexpected OOM killings if memory.oom.group is used
> anywhere in the cgroup tree.
>
> Imagine the following example:
>
> A (oom.group = 1)
> / \
> (OOM) B C
>
> Let's say B's memory.max is exceeded and it's OOMing. The OOM killer
> selects a task in B as a victim, but someone asynchronously moves
> the task into C. mem_cgroup_get_oom_group() will iterate over all
> ancestors of C up to the root cgroup. In theory it had to stop
> at the oom_domain level - the memory cgroup which is OOMing.
> But because B is not an ancestor of C, it's not happening.
> Instead it chooses A (because it's oom.group is set), and kills
> all tasks in A. This behavior is wrong because the OOM happened in B,
> so there is no reason to kill anything outside.
>
> Fix this by checking it the memory cgroup to which the task belongs
> is a descendant of the oom_domain. If not, memory.oom.group should
> be ignored, and the OOM killer should kill only the victim task.
>
> Signed-off-by: Roman Gushchin <guro@...com>
> Reported-by: Dan Schatzberg <dschatzberg@...com>
Acked-by: Johannes Weiner <hannes@...xchg.org>
Powered by blists - more mailing lists