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=-25.1 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=ham 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 A328CC433E0 for ; Sat, 9 Jan 2021 02:23:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A037238EC for ; Sat, 9 Jan 2021 02:23:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A037238EC Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 76F4E8D01C9; Fri, 8 Jan 2021 21:23:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 71F7B8D01B7; Fri, 8 Jan 2021 21:23:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 636238D01C9; Fri, 8 Jan 2021 21:23:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 4A1BE8D01B7 for ; Fri, 8 Jan 2021 21:23:28 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 181EF181AC9B6 for ; Sat, 9 Jan 2021 02:23:28 +0000 (UTC) X-FDA: 77684640096.18.alley03_000c5d9274f7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id F2B78100EC695 for ; Sat, 9 Jan 2021 02:23:27 +0000 (UTC) X-HE-Tag: alley03_000c5d9274f7 X-Filterd-Recvd-Size: 6837 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Sat, 9 Jan 2021 02:23:27 +0000 (UTC) Received: by mail-oo1-f41.google.com with SMTP id k7so2863315ooa.0 for ; Fri, 08 Jan 2021 18:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=O512iOdiQl7IEgpRDKJFQeplTuWfwibmOqpv/4fzERA=; b=ZQSLXT9/DFHCTODimbMizY/fKhhRRuE7vZE/TEUrfMucjwAm68A6KiUZ5AXuADWucB jZavZ/PqwcyhqTTMMBrIZZ3QZjVfHd772M0Cyq3wKIVdQX6FY+60PT2ll38GRJeEvMS2 AjVFKUgDTfusb98LzWGlu/gTnG2/2Ck3HsINcLjec8htrGs9245emOxHX6G+31Dn5HbQ b+5fPgvEHhmRAD9Mu3TaNFj/KDud1BTXsKoTcpR1WuFaMBwKEjom8LhOxKu/wHR0vjbW nAyvjc+sTA04P51ck86N1cMejaM3idB0BN37mTP8lGh1KoRlOqz0AwIgpCMhh/uCOj3J 36Iw== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=O512iOdiQl7IEgpRDKJFQeplTuWfwibmOqpv/4fzERA=; b=Q35BNbTs1p+y/fxQj4+yyRowu66/ld4IBdgvNkhsyZq38fIC4hFxWy1jQCfEPrNkQ6 +olnKH7XdX/Q8sHN8m5wC16dqUCr7NTOPnmfqopFSNCLsbgQjRTF7l8YzgDKdf4y23BB 19POMavUwbO0a7kN1dIENg4z/VwGSRELfrklW+5U8D5UB8igbMD5hEiboVcCyaRtE2C4 SK86Ma3szkx0mlFF5zoCQAyzxVtxp56G9GDugEE3dPsY84svswEZdhayvVHlf0rf2ok9 osngR6BKZ8A6jIUsdZRkWlyy7mr09O1+CIw1g/XEE1tJ7ou3neFhxn7PCvDWt4SYjOr+ A5bw== X-Gm-Message-State: AOAM530jOMB06hSQ+Ml6g417crY9v0JlaB0wrpfpzxqwrQp/rxftb6ST s1HzGHmSYGlP8XRJTRu8MBVF5g== X-Google-Smtp-Source: ABdhPJwtu9DUbVYibKPjfPPmuoXTICJS+E8dU1Ezma2JC/Sd3l+R3WccOKyl4/nMLKee3Nxqll6a3Q== X-Received: by 2002:a4a:e294:: with SMTP id k20mr6225934oot.82.1610159006663; Fri, 08 Jan 2021 18:23:26 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id e10sm2150117otr.73.2021.01.08.18.23.25 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 08 Jan 2021 18:23:26 -0800 (PST) Date: Fri, 8 Jan 2021 18:23:09 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Vlastimil Babka cc: Hugh Dickins , Andrew Morton , Hui Su , Alex Shi , Lorenzo Stoakes , Michal Hocko , Johannes Weiner , Shakeel Butt , Roman Gushchin , Baoquan He , Chris Down , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm/memcontrol: fix warning in mem_cgroup_page_lruvec() In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 7 Jan 2021, Vlastimil Babka wrote: > On 1/4/21 6:03 AM, Hugh Dickins wrote: > > Boot a CONFIG_MEMCG=y kernel with "cgroup_disabled=memory" and you are > > met by a series of warnings from the VM_WARN_ON_ONCE_PAGE(!memcg, page) > > recently added to the inline mem_cgroup_page_lruvec(). > > > > An earlier attempt to place that warning, in mem_cgroup_lruvec(), had > > been careful to do so after weeding out the mem_cgroup_disabled() case; > > but was itself invalid because of the mem_cgroup_lruvec(NULL, pgdat) in > > clear_pgdat_congested() and age_active_anon(). > > > > Warning in mem_cgroup_page_lruvec() was once useful in detecting a KSM > > charge bug, so may be worth keeping: but skip if mem_cgroup_disabled(). > > > > Fixes: 9a1ac2288cf1 ("mm/memcontrol:rewrite mem_cgroup_page_lruvec()") > > Signed-off-by: Hugh Dickins > > Acked-by: Vlastimil Babka Thanks. > > > --- > > > > include/linux/memcontrol.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- 5.11-rc2/include/linux/memcontrol.h 2020-12-27 20:39:36.751923135 -0800 > > +++ linux/include/linux/memcontrol.h 2021-01-03 19:38:24.822978559 -0800 > > @@ -665,7 +665,7 @@ static inline struct lruvec *mem_cgroup_ > > { > > struct mem_cgroup *memcg = page_memcg(page); > > > > - VM_WARN_ON_ONCE_PAGE(!memcg, page); > > + VM_WARN_ON_ONCE_PAGE(!memcg && !mem_cgroup_disabled(), page); > > Nit: I would reverse the order of conditions as mem_cgroup_disabled() is either > "return true" or a static key. Not that it matters too much on DEBUG_VM configs... tl;dr I'm going to leave the patch as is. You are certainly right that I was forgetting the static-key-ness of mem_cgroup_disabled() when I put the tests that way round: I was thinking of the already-in-a-register-ness of "memcg"; but had also not realized that page_memcg() just did an "&", so condition bits nicely set already. And I think you are right in principle, that the tests should be better the way you suggest, when static key is in use - in the (unusual) mem_cgroup_disabled() case, though not in the usual enabled case. I refuse to confess how many hours I've spent poring over "objdump -ld"s of lock_page_lruvec_irqsave(), and comparing with how it is patched when the kernel is booted with "cgroup_disable=memory". But I have seen builds where my way round worked out better than yours, for both the enabled and disabled cases (SUSE gcc 9.3.1 was good, in the config I was trying on it); and builds where disabled was treated rather poorly my way (with external call to mem_cgroup_disabled() from lock_page_lruvec() and lock_page_lruvec_irqsave(), but inlined into lock_page_lruvec_irq() - go figure! - with SUSE gcc 10.2.1). I suspect a lot depends on what inlining is done, and on that prior page_memcg() doing its "&", and the second mem_cgroup_disabled() which follows immediately in mem_cgroup_lruvec(): different compilers will make different choices, favouring one or the other ordering. I've grown rather tired of it all (and discovered on the way that static keys depend on CONFIG_JUMP_LABEL=y, which I didn't have in a config I've carried forward through "make oldconfig"s for years - thanks); but not found a decisive reason to change the patch. Hugh > > > return mem_cgroup_lruvec(memcg, pgdat); > > } > > > >