From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F0CBC5519A for ; Mon, 27 Apr 2020 16:52:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C94B92084D for ; Mon, 27 Apr 2020 16:52:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="e6G34f8u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C94B92084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 554D98E0005; Mon, 27 Apr 2020 12:52:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DE3C8E0001; Mon, 27 Apr 2020 12:52:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A62A8E0005; Mon, 27 Apr 2020 12:52:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id 1F4D88E0001 for ; Mon, 27 Apr 2020 12:52:26 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C523F40F4 for ; Mon, 27 Apr 2020 16:52:25 +0000 (UTC) X-FDA: 76754228250.23.nerve03_3239f114de403 X-HE-Tag: nerve03_3239f114de403 X-Filterd-Recvd-Size: 7274 Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Apr 2020 16:52:24 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id v18so8849464qvx.9 for ; Mon, 27 Apr 2020 09:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=uHH5G3ygpt6fz1ZtSnotHqjI9vLZ9l9n/xiOJEspxzY=; b=e6G34f8uAPYUx2k2uaAuy4SLcrPrsnbqi2o0P3Dh+KDsHJE+ILdHRQt/MuYWJj6I9x 9HS629s5ypPl0MtGgXwjCGdlAgNAJQRWV1Ci94LeqkhTRdn4Jjl/eNwOHJzSY2DEsCSN 1h25RYEyTPWPnfyOJA750nfLCYaGATl6uqqu6k4uJhJqWcmhY+qyr2QpWt3SFyqmHOqq Xgf7teNPnBseBh+PUmkvywabwOzBWELdQNQya15Yvo9Tssuyr3OMrUUD+XENqrEwlaW+ XqvzG5eCdMZzoSUdFMuCw7xBFy4WuNclZAY/gYdpI2r2JxR4HlcUqofWZfq/pYl7UrF4 RNZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uHH5G3ygpt6fz1ZtSnotHqjI9vLZ9l9n/xiOJEspxzY=; b=Shc0zL48h+tmGG3f4eQfyZcjugsKF/4poAvWKbi/3fihbraZC8D7QMoRZ5Z4O9cb38 cd36ejIPwOeUpndxYHklZbEfURZMdWu2rvIT7R1ldMQXXrhN8P3gQi+pMxZb4p6mMCVi Uhi4wjIrmuKyGQhMRbhcRCQ1Xc7yTePvVQmD6wMTAWyqxzuWb5QJF8V4xHREPaIRIGAe qBFYDRyLJESmqTN0Q2xZoPjvCBRCYIKGCQP2YkmCTcrdv1RWA6G+wPUtX9zd9rdZun+A RCSbf1fM0Wuo+pXvt14XYPVk+iidCbTXRYfbZ2T8M7/ixKtCCZSY5n82NkNoKwIx2JA6 OmTg== X-Gm-Message-State: AGi0PuYDoc8mfVW+UudequwN0XzQDRVbaa7PawbR7jAx/soj7WWodtGi 4r93LRu+aTVH6uOvfODlWcJZjA== X-Google-Smtp-Source: APiQypKGzBwVtw111Fx8k0Vex9YZnDP8gqisd4acj6TYO6vBc0sd7275uVf5RW7gJI6oezZlh3xKxA== X-Received: by 2002:a0c:e305:: with SMTP id s5mr23797736qvl.234.1588006344115; Mon, 27 Apr 2020 09:52:24 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id q27sm11109873qkn.7.2020.04.27.09.52.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 09:52:23 -0700 (PDT) Date: Mon, 27 Apr 2020 12:52:12 -0400 From: Johannes Weiner To: Michal Hocko Cc: Yafang Shao , akpm@linux-foundation.org, vdavydov.dev@gmail.com, linux-mm@kvack.org, Chris Down , Roman Gushchin , stable@vger.kernel.org Subject: Re: [PATCH] mm, memcg: fix wrong mem cgroup protection Message-ID: <20200427165212.GA29022@cmpxchg.org> References: <20200423061629.24185-1-laoar.shao@gmail.com> <20200424131450.GA495720@cmpxchg.org> <20200424142958.GF11591@dhcp22.suse.cz> <20200424151013.GA525165@cmpxchg.org> <20200424162103.GK11591@dhcp22.suse.cz> <20200424165103.GA575707@cmpxchg.org> <20200427082524.GC28637@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200427082524.GC28637@dhcp22.suse.cz> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Apr 27, 2020 at 10:25:24AM +0200, Michal Hocko wrote: > On Fri 24-04-20 12:51:03, Johannes Weiner wrote: > > On Fri, Apr 24, 2020 at 06:21:03PM +0200, Michal Hocko wrote: > > > On Fri 24-04-20 11:10:13, Johannes Weiner wrote: > > > > On Fri, Apr 24, 2020 at 04:29:58PM +0200, Michal Hocko wrote: > > > > > On Fri 24-04-20 09:14:50, Johannes Weiner wrote: > > > > > > On Thu, Apr 23, 2020 at 02:16:29AM -0400, Yafang Shao wrote: > > > > > > > This patch is an improvement of a previous version[1], as the previous > > > > > > > version is not easy to understand. > > > > > > > This issue persists in the newest kernel, I have to resend the fix. As > > > > > > > the implementation is changed, I drop Roman's ack from the previous > > > > > > > version. > > > > > > > > > > > > Now that I understand the problem, I much prefer the previous version. > > > > > > > > > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > > > > > index 745697906ce3..2bf91ae1e640 100644 > > > > > > --- a/mm/memcontrol.c > > > > > > +++ b/mm/memcontrol.c > > > > > > @@ -6332,8 +6332,19 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root, > > > > > > > > > > > > if (!root) > > > > > > root = root_mem_cgroup; > > > > > > - if (memcg == root) > > > > > > + if (memcg == root) { > > > > > > + /* > > > > > > + * The cgroup is the reclaim root in this reclaim > > > > > > + * cycle, and therefore not protected. But it may have > > > > > > + * stale effective protection values from previous > > > > > > + * cycles in which it was not the reclaim root - for > > > > > > + * example, global reclaim followed by limit reclaim. > > > > > > + * Reset these values for mem_cgroup_protection(). > > > > > > + */ > > > > > > + memcg->memory.emin = 0; > > > > > > + memcg->memory.elow = 0; > > > > > > return MEMCG_PROT_NONE; > > > > > > + } > > > > > > > > > > Could you be more specific why you prefer this over the > > > > > mem_cgroup_protection which doesn't change the effective value? > > > > > Isn't it easier to simply ignore effective value for the reclaim roots? > > > > > > > > Because now both mem_cgroup_protection() and mem_cgroup_protected() > > > > have to know about the reclaim root semantics, instead of just the one > > > > central place. > > > > > > Yes this is true but it is also potentially overwriting the state with > > > a parallel reclaim which can lead to surprising results > > > > Checking in mem_cgroup_protection() doesn't avoid the fundamental race: > > > > root > > `- A (low=2G, elow=2G, max=3G) > > `- A1 (low=2G, elow=2G) > > > > If A does limit reclaim while global reclaim races, the memcg == root > > check in mem_cgroup_protection() will reliably calculate the "right" > > scan value for A, which has no pages, and the wrong scan value for A1 > > where the memory actually is. > > I am sorry but I do not see how A1 would get wrong scan value. I mistyped the example. If we're in limit reclaim in A, elow should look like this: root `- A (low=2G, max=3G -> elow=0) `- A1 (low=0G -> elow=0) But if global reclaim were to kick in, it could overwrite elow to this: root `- A (low=2G, max=3G -> elow=2G) `- A1 (low=0G -> elow=2G) (This is with the recursive memory.low semantics, of course.) > > I'm okay with fixing the case where a really old left-over value is > > used by target reclaim. > > > > I don't see a point in special casing this one instance of a > > fundamental race condition at the expense of less robust code. > > I am definitely not calling to fragment the code. I do agree that having > a special case in mem_cgroup_protection is quite non-intuitive. > The existing code is quite hard to reason about in its current form > as we can see. If we can fix all that in mem_cgroup_protected then no > objections from me at all. Agreed, sounds reasonable.