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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 753B9C54FCB for ; Fri, 24 Apr 2020 10:57:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3934A20776 for ; Fri, 24 Apr 2020 10:57:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SHw/vTc1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3934A20776 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BB4698E0005; Fri, 24 Apr 2020 06:57:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B65768E0003; Fri, 24 Apr 2020 06:57:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7BB98E0005; Fri, 24 Apr 2020 06:57:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 8D3FA8E0003 for ; Fri, 24 Apr 2020 06:57:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4BE5B5DEB for ; Fri, 24 Apr 2020 10:57:49 +0000 (UTC) X-FDA: 76742448258.20.grain61_7e756a2aa854d X-HE-Tag: grain61_7e756a2aa854d X-Filterd-Recvd-Size: 5443 Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Apr 2020 10:57:48 +0000 (UTC) Received: by mail-io1-f68.google.com with SMTP id o127so9911877iof.0 for ; Fri, 24 Apr 2020 03:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W14NOQNLgCCF+107wQXaNZVar3MGasMy5WRrpNRQT4U=; b=SHw/vTc1MxAyac2wBzilgn8X3tBU6XIE+102l6O4e7B7BIfTusHPr9hBScjrGtLub2 cJOMUQwIakcIQc5Q8CTiOu3AlC5eUYOil4W9m7WmkDVGZgnp/lf4rxaOfFm/HqZk4F4K 97xruXO4OYg7uRRL3+d6RL5X20Shmy/BUhoKwUatl3636sKODjgpenkZ1BafjdqmveOX v7mk0FMXqh1PL/ImuC2MADjDRO9AhNoQ4b4Bgto4iPXO53jU/m+IWtDpFSeEShRb+ZNS mRFuWT1dJq7POK29Uje1KEm8+xtBUYG6V7AvwuL/srEKkgFk1hL5oA+VZNfSgymahKh6 wYrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W14NOQNLgCCF+107wQXaNZVar3MGasMy5WRrpNRQT4U=; b=TxgmL8phlHdHz0bzpFMMHbIg3XXZBlhbPxYoUBZ2pdGS8k71oynx17LhX0tZZ4dLNg ch+ggXsGkV195r8YKeXifUi9lmEgQA6PWWerZ6lEYoeKaMHz1uPwM9ZPtLwbkQnE8bZA W+e2N2GmASwDx148Aj+qSpNUr6/v1N3MqfyjbQ+EErNg0R3MRrcNoOx3cuaP/BJqvMdE ppZADTLzBMC/TNwkU3zGI97hZYHrxxA+LQbmUaykGllt+TRFt+VUvw8Q8X65a9Ho3ERR Mb79rjOueYAxUvmnmMtJLTkd07iPIuPVJ6aoPwlAyjNQF8IQlaDwRz+Uk2LaAP/lGENp Sn2g== X-Gm-Message-State: AGi0PuYnr6MOVGJ7iO3lLpxpsbiAoTwoNvV+EzWA0zI7Y6Tn5/4ix0t8 Z8Ch5SuFTK/mzwaUjb+zh1/+i2ymPiheuRFCiy4= X-Google-Smtp-Source: APiQypLXca/a7phxEASsLYORG01eI9t1phsfw0DunZu0lpR8EHvRoISCb3tenDi3OsgWKQFQE/+Kj/MBHgwsREWxEEw= X-Received: by 2002:a02:ccad:: with SMTP id t13mr7861102jap.64.1587725868245; Fri, 24 Apr 2020 03:57:48 -0700 (PDT) MIME-Version: 1.0 References: <20200423061629.24185-1-laoar.shao@gmail.com> <20200423153323.GA1318256@chrisdown.name> <20200423211319.GC83398@carbon.DHCP.thefacebook.com> <20200424104041.GE11591@dhcp22.suse.cz> In-Reply-To: <20200424104041.GE11591@dhcp22.suse.cz> From: Yafang Shao Date: Fri, 24 Apr 2020 18:57:10 +0800 Message-ID: Subject: Re: [PATCH] mm, memcg: fix wrong mem cgroup protection To: Michal Hocko Cc: Roman Gushchin , Chris Down , Andrew Morton , Vladimir Davydov , Linux MM , stable@vger.kernel.org, Johannes Weiner Content-Type: text/plain; charset="UTF-8" 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 Fri, Apr 24, 2020 at 6:40 PM Michal Hocko wrote: > > On Thu 23-04-20 14:13:19, Roman Gushchin wrote: > > 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. > > Do we have any means to quantify the effect? > > I do understand the racy nature of the effective protection values. We > do update them in mem_cgroup_protected and that handles the > reclaim_target == memcg case already. So why do we care later on in > mem_cgroup_protection? And why don't we care about any other concurrent > reclaimers which have a different reclaim memcg target? This just > doesn't make any sense. > No, you missed the point. The issue pointed by me isn't related with racy. Roman also explained that the racy is not the point. > Either we do care about races because they are harmful and then we care > for all possible case or we don't and this patch doesn't really any big > value. Or I still miss the point. > The real point is memcg relcaim will get a wrong value from mem_cgroup_protection() after memory.emin is set. Suppose target memcg has memory.current is 2G and memory.min is 2G, in memcg reclaim, the scan count will be (SWAP_CLUSTER_MAX>>sc->priority), rather than (lruvec_size >> sc->priority). That's a slowdown, and that's explained by Roman as well. -- Thanks Yafang