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 C6DC1C11F65 for ; Wed, 30 Jun 2021 21:21:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3D9896146D for ; Wed, 30 Jun 2021 21:21:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D9896146D 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 703F98D01C9; Wed, 30 Jun 2021 17:21:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D9FD8D01C8; Wed, 30 Jun 2021 17:21:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 553278D01C9; Wed, 30 Jun 2021 17:21:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 261C48D01C8 for ; Wed, 30 Jun 2021 17:21:18 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id F0D011804EA77 for ; Wed, 30 Jun 2021 21:21:17 +0000 (UTC) X-FDA: 78311660994.30.79B2EFF Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf01.hostedemail.com (Postfix) with ESMTP id 5F53DD00014F for ; Wed, 30 Jun 2021 21:21:17 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id pf4-20020a17090b1d84b029016f6699c3f2so5268681pjb.0 for ; Wed, 30 Jun 2021 14:21:17 -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=Fr9/V6zIlyWck7HPPeS/TCISALLUxUMSsg+X8S97SXI=; b=IHSBJTW86/4n83zVuVdOYB3dXkYzVbUh3RZq3+9raR0OesfrwlcgGpsCSG22rwBLa8 5tZM0tz7yNIlyQ+UukH++/9forrJNhx71wU56uudMVEHfT2eTLz5FuzvcvabzL/b3DgS FaexCwnP9dqgR81LBpnq6dPUvVokwVh5E20tfSclZYpmarmNA7Gv6IwQbkZPafS7J2cv gjjX251lVq3VJrcWOK821GgzrLCMxir0gtU9TFP6uyc3qbggepQByhTqmPgI3rZWGAFn jIGyjmjG4ynnEbfjtC52ENZpDkYsnDVjrCdguiGd9tq6+9bvVAiI+DQbWD3QWATYCWbp Pf/w== 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=Fr9/V6zIlyWck7HPPeS/TCISALLUxUMSsg+X8S97SXI=; b=CXIaLezosM4J6F06Y5rfmQhANXZ77Ua6JSoiObMmWMtcOZAq8aMWMW9MP305ZMWeRI vo0roV9EIkqB1HAmXvA6QCn+D2heuNS8T6moskPvFxR7+mb2mcDVDZ8qPVu38d6BVP9d sRWF63fJBvQeAHCwortBw2Qd9VB5GzDMUdLMCypXZ3ReM3TSBKMB8IakM8/uW3R2LqNP 6pAx0nlg3x2TSfqUa5V0V5I9ulp5c7vahZkcvJgkBiUAgENtv83m8L9xTy53crPITfpz yodGDyUYjn0KCfE0lCTtwFkmTSdIwl0xgg/skp2p5Q6XqSuG2TvJoqI2Eej+1C2rWaPQ eX9Q== X-Gm-Message-State: AOAM531knuDh5fzBQRUa4+ng7W7PaTirIjOAfQ4ftxEPuw0tREM8p221 fiVuTHV4Bddk1UFAUkZ5SfKjHw== X-Google-Smtp-Source: ABdhPJzg0SlYb5DEfXzjiZKgf2sG7J7p/O1fYQHzHmIAbYU6pKKs+GWIUg5CMb3JadmDuddP0koIuQ== X-Received: by 2002:a17:90a:3fcd:: with SMTP id u13mr6639295pjm.182.1625088076271; Wed, 30 Jun 2021 14:21:16 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:14ba]) by smtp.gmail.com with ESMTPSA id i18sm10900990pfa.37.2021.06.30.14.21.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Jun 2021 14:21:15 -0700 (PDT) Date: Wed, 30 Jun 2021 17:21:12 -0400 From: Johannes Weiner To: Matthew Wilcox Cc: linux-mm@kvack.org, cgroups@vger.kernel.org, Michal Hocko , Vladimir Davydov Subject: Re: [PATCH v3 15/18] mm/memcg: Add mem_cgroup_folio_lruvec() Message-ID: References: <20210630040034.1155892-1-willy@infradead.org> <20210630040034.1155892-16-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5F53DD00014F X-Stat-Signature: c7xy4fiaq7b8uxb1e8jaijw8qxoozdia Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=IHSBJTW8; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf01.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-HE-Tag: 1625088077-537988 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 Wed, Jun 30, 2021 at 08:18:33PM +0100, Matthew Wilcox wrote: > On Wed, Jun 30, 2021 at 05:00:31AM +0100, Matthew Wilcox (Oracle) wrote: > > This is the folio equivalent of mem_cgroup_page_lruvec(). > > I'm just going through and removing the wrappers. > > Why is this function called this? There's an odd mix of > > lock_page_memcg() This was chosen to match lock_page(). > page_memcg() And this to match page_mapping(), page_zone() etc. > count_memcg_page_event() count_vm_event() > split_page_memcg() split_page(), split_page_owner() > mem_cgroup_charge() > mem_cgroup_swapin_charge_page() These are larger, heavier subsystem API calls that modify all kinds of state, not just the page. Hence the namespacing. With the smaller getter/setter type functions on pages we have traditionally used _ rather than page_, simply because the page is such a low-level object and many functions do sequences of page manipulations. Namespacing would turn them into: page_do_this(page); page_set_that(page); page_lock(page); if (page_is_blah(page)) page_mark_foo(page); page_unlock(page); page_put(page); which is hard on the reader because it obscures the salient part of each line behind repetetive boiler plate. > mem_cgroup_lruvec() This is arguably not a namespace prefix, but rather an accessor function to look up the memcg's lruvec. > mem_cgroup_from_task() This is a pattern to look up memcgs from various objects: - mem_cgroup_from_css() - mem_cgroup_from_counter() - mem_cgroup_from_id() - mem_cgroup_from_seq() - mem_cgroup_from_obj() and we used to have mem_cgroup_from_page() at some point... > I'd really like to call this function folio_lruvec(). That would be a better name indeed. However, pairing renames with conversion is worrisome because it means having two unintuitively diverging names for the same operation in the API during a time where everybody has to relearn the code base already. Please either precede it with a rename to page_lruvec(), or keep the existing naming pattern in the conversion. > It happens to behave differently if the folio is part of a memcg, > but conceptually, lruvecs aren't particularly tied to memcgs. Conceptually, lruvecs are always tied to a memcg. On !CONFIG_MEMCG kernels that just happens to be the root cgroup. But because it's an accessor to a page attribute, dropping the namespacing prefix is in line with things like page_memcg().