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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, 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 186F7C10DCE for ; Tue, 24 Mar 2020 01:06:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D132920722 for ; Tue, 24 Mar 2020 01:06:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="HWzfjzUB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D132920722 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 66F776B00A0; Mon, 23 Mar 2020 21:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61FDE6B00A1; Mon, 23 Mar 2020 21:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 534236B00A2; Mon, 23 Mar 2020 21:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 3C0C96B00A0 for ; Mon, 23 Mar 2020 21:06:36 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 12D801857AB14 for ; Tue, 24 Mar 2020 01:06:36 +0000 (UTC) X-FDA: 76628465592.19.table22_90e28d7c05207 X-HE-Tag: table22_90e28d7c05207 X-Filterd-Recvd-Size: 5524 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Mar 2020 01:06:35 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6257720714; Tue, 24 Mar 2020 01:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585011994; bh=nkAaU5b3pOynaIIlMjxIm1aRxWKaQfp+QZvKhnVa+sE=; h=Date:From:To:Subject:In-Reply-To:References:From; b=HWzfjzUBiYLfTCpe6yT40lyJiEH4pT03ogcytuWMa2lWP+TZpLohXGQ4NH7oTZzkk CgEnnqksCVnPMNMInNc+SsAX9uDxHb7kQ2ZkRavRrjxsMp+D4BN+WH2WIGdy5Ipev/ NUSke5sMT2a1zQdDITWBqMANk4JvoAUqirOsy0EQ= Date: Mon, 23 Mar 2020 18:06:33 -0700 From: Andrew Morton To: Roman Gushchin , Johannes Weiner , Michal Hocko , , , , Bharata B Rao , Subject: Re: [PATCH] mm: fork: fix kernel_stack memcg stats for various stack implementations Message-Id: <20200323180633.5e75654282d076d74766bd88@linux-foundation.org> In-Reply-To: <20200323180358.7603217aa9955f298255da4e@linux-foundation.org> References: <20200303233550.251375-1-guro@fb.com> <20200321164856.be68344b7fac84b759e23727@linux-foundation.org> <20200324004221.GA36662@carbon.dhcp.thefacebook.com> <20200323180358.7603217aa9955f298255da4e@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Mon, 23 Mar 2020 18:03:58 -0700 Andrew Morton wrote: > On Mon, 23 Mar 2020 17:42:21 -0700 Roman Gushchin wrote: > > > How about this one? I've merged them into one and stripped it a little bit. > > > > Thanks! > > > > Yes, that looks good. Here's the delta from the previously reviewed > version. I think it's valid to retain those acks and revewed-by's. > > And here's the altered "mm: memcg/slab: introduce mem_cgroup_from_obj()", which I have renamed to "mm: memcg/slab: use mem_cgroup_from_obj()": The end result is slightly different - mem_cgroup_from_obj() will now end up inside #ifdef CONFIG_MEMCG_KMEM. Should I undo that? From: Roman Gushchin Subject: mm: memcg/slab: use mem_cgroup_from_obj() Sometimes we need to get a memcg pointer from a charged kernel object. The right way to get it depends on whether it's a proper slab object or it's backed by raw pages (e.g. it's a vmalloc alloction). In the first case the kmem_cache->memcg_params.memcg indirection should be used; in other cases it's just page->mem_cgroup. To simplify this task and hide the implementation details let's use the mem_cgroup_from_obj() helper, which takes a pointer to any kernel object and returns a valid memcg pointer or NULL. Passing a kernel address rather than a pointer to a page will allow to use this helper for per-object (rather than per-page) tracked objects in the future. The caller is still responsible to ensure that the returned memcg isn't going away underneath: take the rcu read lock, cgroup mutex etc; depending on the context. mem_cgroup_from_kmem() defined in mm/list_lru.c is now obsolete and can be removed. Link: http://lkml.kernel.org/r/20200117203609.3146239-1-guro@fb.com Signed-off-by: Roman Gushchin Acked-by: Yafang Shao Reviewed-by: Shakeel Butt Cc: Michal Hocko Cc: Johannes Weiner Cc: Vladimir Davydov Signed-off-by: Andrew Morton --- mm/list_lru.c | 12 +----------- mm/memcontrol.c | 5 ++--- 2 files changed, 3 insertions(+), 14 deletions(-) --- a/mm/list_lru.c~mm-memcg-slab-introduce-mem_cgroup_from_obj +++ a/mm/list_lru.c @@ -57,16 +57,6 @@ list_lru_from_memcg_idx(struct list_lru_ return &nlru->lru; } -static __always_inline struct mem_cgroup *mem_cgroup_from_kmem(void *ptr) -{ - struct page *page; - - if (!memcg_kmem_enabled()) - return NULL; - page = virt_to_head_page(ptr); - return memcg_from_slab_page(page); -} - static inline struct list_lru_one * list_lru_from_kmem(struct list_lru_node *nlru, void *ptr, struct mem_cgroup **memcg_ptr) @@ -77,7 +67,7 @@ list_lru_from_kmem(struct list_lru_node if (!nlru->memcg_lrus) goto out; - memcg = mem_cgroup_from_kmem(ptr); + memcg = mem_cgroup_from_obj(ptr); if (!memcg) goto out; --- a/mm/memcontrol.c~mm-memcg-slab-introduce-mem_cgroup_from_obj +++ a/mm/memcontrol.c @@ -759,13 +759,12 @@ void __mod_lruvec_state(struct lruvec *l void __mod_lruvec_slab_state(void *p, enum node_stat_item idx, int val) { - struct page *page = virt_to_head_page(p); - pg_data_t *pgdat = page_pgdat(page); + pg_data_t *pgdat = page_pgdat(virt_to_page(p)); struct mem_cgroup *memcg; struct lruvec *lruvec; rcu_read_lock(); - memcg = memcg_from_slab_page(page); + memcg = mem_cgroup_from_obj(p); /* Untracked pages have no memcg, no lruvec. Update only the node */ if (!memcg || memcg == root_mem_cgroup) { _