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=-23.3 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_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 2BBF9C433DB for ; Mon, 1 Mar 2021 18:12:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A494E64FA6 for ; Mon, 1 Mar 2021 18:12:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A494E64FA6 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 302FB8D0093; Mon, 1 Mar 2021 13:12:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 28B918D0063; Mon, 1 Mar 2021 13:12:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12C408D0093; Mon, 1 Mar 2021 13:12:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id ECD328D0063 for ; Mon, 1 Mar 2021 13:12:06 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A6F821E0B for ; Mon, 1 Mar 2021 18:12:06 +0000 (UTC) X-FDA: 77872099452.26.947A8D9 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf28.hostedemail.com (Postfix) with ESMTP id 45D3720001EA for ; Mon, 1 Mar 2021 18:11:59 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id u4so20579219ljh.6 for ; Mon, 01 Mar 2021 10:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BGU0eUrGcHK/RDV2rfGKNSJvLH9RO1hVgeZSC29kjwo=; b=ht1sFzXFGRfS8LWY4p2VzOH9ey6K1YEdVoK6ois+19WsBeTJoAIp0tgzWGYsYZupDU qJFKb8PFVL3nJiTyit/TnKA8aEKQDxwwg71VD/oSYIQZaacqGy9Zwb2Fq8Pbi+ExaAsQ VL6amJZRvFp93GD92cT48zqHKb0jTeHHHfyb5JEJEiyWdxMJa/5UUKgZZmbMNPXLu1L+ d7BSvB3G1hdvVn0qWuUDLAj/ndRvD7LVDuiJLAM1+CPfKY5NqqlhAQW6YxI5bLXG/pkJ l/f7aZVczU7/iYKir9kKh5hnoT+daU64GUZ0uEi3m6Kvqzx8q9w4NEkVdDFmjzlboJ+r yNCA== 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=BGU0eUrGcHK/RDV2rfGKNSJvLH9RO1hVgeZSC29kjwo=; b=Su+m2OgkYCjMoEn4GiGSaDOQzO1rHipfwuikjb7a73DsBz1MbBJYqqktwTN8CYALzq qOz8rSva9mZJzLXlaIYC4iZJXBgS0wCkRGDdrtjLWE8fYeWv860LbMBRKtnQrK3Lqj+b L4LWaB6lXVd6QEhpCG7rNy67gakx0PJ4QoUIMDFPGBtwmFir0CH/b0FtLKeMcZdTd+9F 6M1y4jNclrK9KDTcZ0UhYlR4haafgtkLHOilMQ1sfgyJC79MXl7MZzFh6cprb+P5dx04 Tv1Q9oQLacbq/YbkznFHek1dIoeOvtP4iWEyBq2Q8PPXbnoZvrRUowPcfC7brzRLFbpG W5LQ== X-Gm-Message-State: AOAM533yCXZ2ZAY3TzPXsOJfOS1418D8SqH/nIC6TpF/PSJy/wx6NYU8 aNVUIXHWMb3DzOX1D7wnfJT7nyQHU1IuL4Z/A7tkpQ== X-Google-Smtp-Source: ABdhPJyyN10CMbekqIe2EaCLHXVwEmhEw2eA0ojmVgi3XY81XzPa0cvQd4lzpVVcj9/BVccaJ8HjfF/Ze2+dV2hAXeM= X-Received: by 2002:a2e:9cc4:: with SMTP id g4mr981268ljj.34.1614622317485; Mon, 01 Mar 2021 10:11:57 -0800 (PST) MIME-Version: 1.0 References: <20210301062227.59292-1-songmuchun@bytedance.com> <20210301062227.59292-3-songmuchun@bytedance.com> In-Reply-To: <20210301062227.59292-3-songmuchun@bytedance.com> From: Shakeel Butt Date: Mon, 1 Mar 2021 10:11:45 -0800 Message-ID: Subject: Re: [PATCH 2/5] mm: memcontrol: make page_memcg{_rcu} only applicable for non-kmem page To: Muchun Song Cc: Alexander Viro , Jan Kara , Amir Goldstein , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , john.fastabend@gmail.com, kpsingh@kernel.org, Ingo Molnar , "Peter Zijlstra (Intel)" , Juri Lelli , Vincent Guittot , dietmar.eggemann@arm.com, Steven Rostedt , Benjamin Segall , Mel Gorman , bristot@redhat.com, Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Roman Gushchin , Alex Shi , alexander.h.duyck@linux.intel.com, Chris Down , Wei Yang , Vlastimil Babka , Mathieu Desnoyers , Peter Oskolkov , Jann Horn , Joonsoo Kim , daniel.vetter@ffwll.ch, Waiman Long , Michel Lespinasse , Christian Brauner , "Eric W. Biederman" , Kees Cook , krisman@collabora.com, esyr@redhat.com, Suren Baghdasaryan , Marco Elver , linux-fsdevel , LKML , netdev , bpf , Cgroups , Linux MM , duanxiongchun@bytedance.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 45D3720001EA X-Stat-Signature: e3q3xsj6mj8sps9xenqwyyppb3n1dr57 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail-lj1-f179.google.com; client-ip=209.85.208.179 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614622319-692122 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 Sun, Feb 28, 2021 at 10:25 PM Muchun Song wrote: > > We want to reuse the obj_cgroup APIs to reparent the kmem pages when > the memcg offlined. If we do this, we should store an object cgroup > pointer to page->memcg_data for the kmem pages. > > Finally, page->memcg_data can have 3 different meanings. > > 1) For the slab pages, page->memcg_data points to an object cgroups > vector. > > 2) For the kmem pages (exclude the slab pages), page->memcg_data > points to an object cgroup. > > 3) For the user pages (e.g. the LRU pages), page->memcg_data points > to a memory cgroup. > > Currently we always get the memcg associated with a page via page_memcg > or page_memcg_rcu. page_memcg_check is special, it has to be used in > cases when it's not known if a page has an associated memory cgroup > pointer or an object cgroups vector. Because the page->memcg_data of > the kmem page is not pointing to a memory cgroup in the later patch, > the page_memcg and page_memcg_rcu cannot be applicable for the kmem > pages. In this patch, we introduce page_memcg_kmem to get the memcg > associated with the kmem pages. And make page_memcg and page_memcg_rcu > no longer apply to the kmem pages. > > In the end, there are 4 helpers to get the memcg associated with a > page. The usage is as follows. > > 1) Get the memory cgroup associated with a non-kmem page (e.g. the LRU > pages). > > - page_memcg() > - page_memcg_rcu() Can you rename these to page_memcg_lru[_rcu] to make them explicitly for LRU pages? > > 2) Get the memory cgroup associated with a kmem page (exclude the slab > pages). > > - page_memcg_kmem() > > 3) Get the memory cgroup associated with a page. It has to be used in > cases when it's not known if a page has an associated memory cgroup > pointer or an object cgroups vector. Returns NULL for slab pages or > uncharged pages, otherwise, returns memory cgroup for charged pages > (e.g. kmem pages, LRU pages). > > - page_memcg_check() > > In some place, we use page_memcg to check whether the page is charged. > Now we introduce page_memcg_charged helper to do this. > > This is a preparation for reparenting the kmem pages. To support reparent > kmem pages, we just need to adjust page_memcg_kmem and page_memcg_check in > the later patch. > > Signed-off-by: Muchun Song > --- [snip] > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -855,10 +855,11 @@ void __mod_lruvec_page_state(struct page *page, enum node_stat_item idx, > int val) > { > struct page *head = compound_head(page); /* rmap on tail pages */ > - struct mem_cgroup *memcg = page_memcg(head); > + struct mem_cgroup *memcg; > pg_data_t *pgdat = page_pgdat(page); > struct lruvec *lruvec; > > + memcg = PageMemcgKmem(head) ? page_memcg_kmem(head) : page_memcg(head); Should page_memcg_check() be used here? > /* Untracked pages have no memcg, no lruvec. Update only the node */ > if (!memcg) { > __mod_node_page_state(pgdat, idx, val); > @@ -3170,12 +3171,13 @@ int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order) > */ > void __memcg_kmem_uncharge_page(struct page *page, int order) > { > - struct mem_cgroup *memcg = page_memcg(page); > + struct mem_cgroup *memcg; > unsigned int nr_pages = 1 << order; > > - if (!memcg) > + if (!page_memcg_charged(page)) > return; > > + memcg = page_memcg_kmem(page); > VM_BUG_ON_PAGE(mem_cgroup_is_root(memcg), page); > __memcg_kmem_uncharge(memcg, nr_pages); > page->memcg_data = 0; > @@ -6831,24 +6833,25 @@ static void uncharge_batch(const struct uncharge_gather *ug) > static void uncharge_page(struct page *page, struct uncharge_gather *ug) > { > unsigned long nr_pages; > + struct mem_cgroup *memcg; > > VM_BUG_ON_PAGE(PageLRU(page), page); > > - if (!page_memcg(page)) > + if (!page_memcg_charged(page)) > return; > > /* > * Nobody should be changing or seriously looking at > - * page_memcg(page) at this point, we have fully > - * exclusive access to the page. > + * page memcg at this point, we have fully exclusive > + * access to the page. > */ > - > - if (ug->memcg != page_memcg(page)) { > + memcg = PageMemcgKmem(page) ? page_memcg_kmem(page) : page_memcg(page); Same, should page_memcg_check() be used here?