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=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 2AB8CC433ED for ; Fri, 16 Apr 2021 15:48:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9ED8461222 for ; Fri, 16 Apr 2021 15:48:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9ED8461222 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 1F3A26B0070; Fri, 16 Apr 2021 11:48:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17D346B0071; Fri, 16 Apr 2021 11:48:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F38446B0072; Fri, 16 Apr 2021 11:48:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id CE0746B0070 for ; Fri, 16 Apr 2021 11:48:16 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 814716129 for ; Fri, 16 Apr 2021 15:48:16 +0000 (UTC) X-FDA: 78038661792.31.96F1879 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf02.hostedemail.com (Postfix) with ESMTP id C17EE40002E3 for ; Fri, 16 Apr 2021 15:47:57 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id x11so29235073qkp.11 for ; Fri, 16 Apr 2021 08:48:15 -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=jEiyTnsJBz+3LM/AEUTcCopsniGZUGJiJXoqEYpAchc=; b=GsMQU312d3+bjYcyvWaGgihp/toAeub1wsouXLWaXNwHYTQaB7LwP4IBLj9mu2lQLa 8h8x0rgNlRDCog9rTth+hGVzB34zfq9Hn3qbM0yWNpIEM+M4VgKrqe3l4Muu07uoa450 Pn4cQBsp2krJTlXaDZUKJfDdrEsDatYx/bikcvg3T99IY65JF9VI2D9rfDuL/hSo/kpH 179UmXP0GzkfbtHB8zlDMj+pyZUnUxNL5Y3alLTVYdvXhGgYCirxlTJNb5x0VUwDDlKA 7A4xLUEhJ4m5eLGA0Fe9TfGq4nMexHI/lTIoYQjFJctKJWRPCGh0kF0Kg7Yl5t5wxF40 681g== 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=jEiyTnsJBz+3LM/AEUTcCopsniGZUGJiJXoqEYpAchc=; b=OXDdOW5AplhRGcL3mVmYpztZclBrPt4dMime7zHbb7yNEvkSmzH1ZwVKeTm4K1DuS9 wamGYkQgscGHUEG6rY2FDt/coB1qYfBitNONiQUxoOeRnkOps39krjyXN8LjXzQZAgDU LbVD5cWAxp6BmvDj9D6BCS3OUhiar/2nVZoFXVftglYqT3mzqZ1DCJNhQJkmxCS9wmfp rK7ekEmcyLhu2YJMuxZkDwWCP1dSMUz1ITmh7TCqKviwwC4PV9i28gxFaZsN1MtEKXoD BU6GPL8lsQ/vmSg+fVXBtRTm2eIuFmfu+AVn0dOWEAPUv8yPxjzFIjYKOkRozPUnivQT enkA== X-Gm-Message-State: AOAM531EpY0NR4Yq+qdoLxqEnNNA/ioB6T1H68NMZ/Hhivy3QMm6VLjB 7DgfOEsFwy0dKfkwsPoToKQCUA== X-Google-Smtp-Source: ABdhPJx8OHfpY+zeHutioHIMaFCsw6/lrznUI43UQbq4vAQuxuNUNahlfp72uTPIFNmy8blO6S7sZw== X-Received: by 2002:a37:6f87:: with SMTP id k129mr9461373qkc.470.1618588095311; Fri, 16 Apr 2021 08:48:15 -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 26sm4153612qtd.73.2021.04.16.08.48.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Apr 2021 08:48:14 -0700 (PDT) Date: Fri, 16 Apr 2021 11:48:14 -0400 From: Johannes Weiner To: Waiman Long Cc: Michal Hocko , Vladimir Davydov , Andrew Morton , Tejun Heo , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Muchun Song , Alex Shi , Chris Down , Yafang Shao , Wei Yang , Masayoshi Mizuma , Xing Zhengjun Subject: Re: [PATCH v3 1/5] mm/memcg: Pass both memcg and lruvec to mod_memcg_lruvec_state() Message-ID: References: <20210414012027.5352-1-longman@redhat.com> <20210414012027.5352-2-longman@redhat.com> <59a85df9-3e77-1d43-8673-2ff50a741130@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59a85df9-3e77-1d43-8673-2ff50a741130@redhat.com> X-Stat-Signature: 1o5f7h8p4emhotwetf3gf6w45ja5wkjh X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C17EE40002E3 Received-SPF: none (cmpxchg.org>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail-qk1-f179.google.com; client-ip=209.85.222.179 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618588077-284972 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, Apr 15, 2021 at 12:59:21PM -0400, Waiman Long wrote: > On 4/15/21 12:40 PM, Johannes Weiner wrote: > > On Tue, Apr 13, 2021 at 09:20:23PM -0400, Waiman Long wrote: > > > The caller of mod_memcg_lruvec_state() has both memcg and lruvec readily > > > available. So both of them are now passed to mod_memcg_lruvec_state() > > > and __mod_memcg_lruvec_state(). The __mod_memcg_lruvec_state() is > > > updated to allow either of the two parameters to be set to null. This > > > makes mod_memcg_lruvec_state() equivalent to mod_memcg_state() if lruvec > > > is null. > > > > > > The new __mod_memcg_lruvec_state() function will be used in the next > > > patch as a replacement of mod_memcg_state() in mm/percpu.c for the > > > consolidation of the memory uncharge and vmstat update functions in > > > the kmem_cache_free() path. > > This requires users who want both to pass a pgdat that can be derived > > from the lruvec. This is error prone, and we just acked a patch that > > removes this very thing from mem_cgroup_page_lruvec(). > > > > With the suggestion for patch 2, this shouldn't be necessary anymore, > > though. And sort of underlines my point around that combined function > > creating akwward code above and below it. > > > The reason of passing in the pgdat is because of the caching of vmstat data. > lruvec may be gone if the corresponding memory cgroup is removed, but pgdat > should stay put. That is why I put pgdat in the obj_stock for caching. I > could also put the node id instead of pgdat. Internally storing the pgdat is fine. I was talking about the interface requiring the user to pass redundant information (pgdat, can be derived from lruvec) because the parameter is overloaded to modify the function's behavior, which is unintuitive.