Re: [PATCH] mm, memcg: fix wrong mem cgroup protection

From: Roman Gushchin <guro@fb.com>
To: Chris Down <chris@chrisdown.name>
Cc: Yafang Shao <laoar.shao@gmail.com>, <akpm@linux-foundation.org>,
	<mhocko@kernel.org>, <vdavydov.dev@gmail.com>,
	<linux-mm@kvack.org>, <stable@vger.kernel.org>,
	<hannes@cmpxchg.org>
Subject: Re: [PATCH] mm, memcg: fix wrong mem cgroup protection
Date: Thu, 23 Apr 2020 14:13:19 -0700	[thread overview]
Message-ID: <20200423211319.GC83398@carbon.DHCP.thefacebook.com> (raw)
In-Reply-To: <20200423153323.GA1318256@chrisdown.name>

On Thu, Apr 23, 2020 at 04:33:23PM +0100, Chris Down wrote:
> Hi Yafang,
> 
> I'm afraid I'm just as confused as Michal was about the intent of this patch.
> 
> Can you please be more concise and clear about the practical ramifications
> and demonstrate some pathological behaviour? I really can't visualise what's
> wrong here from your explanation, and if I can't understand it as the person
> who wrote this code, I am not surprised others are also confused :-)
> 
> Or maybe Roman can try to explain, since he acked the previous patch? At
> least to me, the emin/elow behaviour seems fairly non-trivial to reason
> about right now.

Hi Chris!

So the thing is that emin/elow cached values are shared between global and
targeted (caused by memory.max) reclaim. It's racy by design, but in general
it should work ok, because in the end we'll reclaim or not approximately
the same amount of memory.

In the case which Yafang described, the emin value calculated in the process
of the global reclaim leads to a slowdown of the targeted reclaim. It's not
a tragedy, but not perfect too. It seems that the proposed patch makes it better,
and as now I don't see any bad consequences.

Thanks!