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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E2B3C3DA59 for ; Mon, 15 Jul 2024 09:10:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 116116B008C; Mon, 15 Jul 2024 05:10:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C7656B0092; Mon, 15 Jul 2024 05:10:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAA9B6B0093; Mon, 15 Jul 2024 05:10:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CD8C66B008C for ; Mon, 15 Jul 2024 05:10:35 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4F4C181427 for ; Mon, 15 Jul 2024 09:10:35 +0000 (UTC) X-FDA: 82341416430.10.70E2247 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf01.hostedemail.com (Postfix) with ESMTP id 979314000D for ; Mon, 15 Jul 2024 09:10:32 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=H1GdygaB; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721034591; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T/o2DkUWTT7MRjos0RvziyJKUNdD43alem3s9V9ovzk=; b=7PvRXeWzOZuJ6Zb71HWBwz9TNgFydflP5u+FJ5QIwGQO5rsfjisT0iDQEiqv+iv/m0dO3n YhDj519N/mTwYfaDOj/+i3sbCCIMYnHUgccvdCCFIoaTEmJbdSCba30ULh6DqWvVFpV9yy Jbn3zkjqG0mf1LllV3hXtdYQ+NddzoI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721034591; a=rsa-sha256; cv=none; b=2pLBkb/GHI/I5eS7DEvo7rgep7uetAy4K82ssBDlrx/jGcBh89Zp5DydNKbSh1oqfAtAlr Rs+XGo6aAHUqGDg9IWkO1hQzVc95JvZwvYiK1CfY7fEQ3/aA0WtSMvQj8hsnSwoMTcm1n7 RBuXItAt/5e/+DxqpoNAn7GIuu0LKtU= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=H1GdygaB; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=muchun.song@linux.dev X-Envelope-To: kasong@tencent.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1721034630; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T/o2DkUWTT7MRjos0RvziyJKUNdD43alem3s9V9ovzk=; b=H1GdygaBtPQ9lmYgtTiLxwiIMrwehLG6xvNkOpidFcILQCetOpZ9JZZgCoEKTejY/6QLxZ rF+7wQZTzRoHgL1EJyR+yHkhyAoDB9QWV0ru3JmSx6os9yN/JKKJZ9tXBcFnyaGSMX9Kp0 lp7YPJYKyXBSwrURPt602JxvkarzahA= X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: willy@infradead.org X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: roman.gushchin@linux.dev X-Envelope-To: longman@redhat.com X-Envelope-To: shakeelb@google.com X-Envelope-To: nphamcs@gmail.com X-Envelope-To: mhocko@suse.com X-Envelope-To: zhouchengming@bytedance.com X-Envelope-To: zhengqi.arch@bytedance.com X-Envelope-To: chrisl@kernel.org X-Envelope-To: yosryahmed@google.com X-Envelope-To: ying.huang@intel.com X-Envelope-To: linux-mm@kvack.org Message-ID: <66591895-356b-48bf-b4ac-5cec5c29ae8d@linux.dev> Date: Mon, 15 Jul 2024 17:10:21 +0800 MIME-Version: 1.0 Subject: Re: [PATCH 4/7] mm/list_lru: code clean up for reparenting To: Kairui Song Cc: Andrew Morton , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Waiman Long , Shakeel Butt , Nhat Pham , Michal Hocko , Chengming Zhou , Qi Zheng , Chris Li , Yosry Ahmed , "Huang, Ying" , linux-mm@kvack.org References: <20240624175313.47329-1-ryncsn@gmail.com> <20240624175313.47329-5-ryncsn@gmail.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20240624175313.47329-5-ryncsn@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 979314000D X-Stat-Signature: w9drczr966ch7p8qxq6ww3w83butite8 X-Rspam-User: X-HE-Tag: 1721034632-507305 X-HE-Meta: U2FsdGVkX1/dWeujM3YjGg3xjIPM/iWjWXXfsb3nUdbRPGnPPjZjWp5q8vfVj1DjdYDAGVMw1gPA3Et+PkOOt3moT0gEXZb9BFdTEze+4Bmjv+gXXRrEJFjswGO0sRCf4TYrCNbMwSqRcLMz2t2SZa8FwSY3pcqFInUBCsJdLAfgZb7RHfoIenH8lEYvbV8INCpAT+fXJLMez0Kcbh3NKm406HvhU51QOznZ+3UJNO+1xdPcNS7lda+XB6e3/SB3QOr9BUfTOtPQuh88uGw6aeIxZ9kHgrEcIKU8VqOl+tyfiVDVFHGJDspgD9mH4+Hui+JpA1yZ5lGwK2pWo1v90wZgg109Mi7AUk4jKe1ewfJ1jYLpKTPsouekInro2azz9RxfmSpzsvgb/zSBnfNtH3Rzx7C65PHA7o+P5RJFmzrAtNtA06c09IQo6XQ/Kg+/WCRN5YvVlg3cwSflx+zTHZ7LFqYaPA5QAtZd2An3KOtxO4EG9Kove4Y0N43b1ZxymfinmbvW6ytmgt2ot+uLmeN+d3W37WcYtbwGHpQYB6hY31heXZh61IpUc1J6aNi8yLA9kv4OL6HzKeyN4Pr3O0EracFRNhxgmoZlTMwOLIe456eUbzKNZHAuPMoeN1c+ON7eXPiRAJPjdgFdRvjFa7qqFwRjUiR6w7iwTw4ofaETh/Lg+iAlx94HTTwzmR6JflbzK5naeKgcF9YNFoKtKEGpFBlc7rmVgvlI2fb2DDPlW2cI5Sncj/lPtnjG1aA4p6ek0p49tWWxFfvcSO43Sic2/oLaGthLWu5bIa0lVrMQ6OMxGW+yt25U4QJwR03EzcfmdWf0S0Oa6kFSXb3RgrkRtYwj+PT6u+Gvu6gejNPFNAVrZXQ/WcZoGDJs6GIixwqbUkmf/MC0/WjpXXsvnF/EqjzMF90iQUNMYKqv2V0SaiWviVfMb5mp94FvcCvOTlsGp2SNTFbbAYeItXG 4Yx0kcsz tBmqbjdKcsJ+SEpuMdITtjiondLEYlNuMIR4nrMYTFSmNpUDKTKTUsLtfh9o9SynBnxaYr3MdfCQecwdkeJCN3JxCypipyPe1HdF7/iFHIeoa5bKeLHiGrQVl5+fY93jVFRmbRA2y+aY5J9tWbFNAdEM24SlRyJ0TWY2ADfezgOM3Ws1gjr8AGFkzeoRwPuunhu7Et8AW9T28v3+i4zCtEFeyTjAqBhE+SjGdkFSiwAUiJ60= 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: List-Subscribe: List-Unsubscribe: On 2024/6/25 01:53, Kairui Song wrote: > From: Kairui Song > > No feature change, just change of code structure and fix comment. > > The list lrus are not empty until memcg_reparent_list_lru_node() calls > are all done, so the comments in memcg_offline_kmem were slightly > inaccurate. > > Signed-off-by: Kairui Song > --- > mm/list_lru.c | 39 +++++++++++++++++---------------------- > mm/memcontrol.c | 7 ------- > 2 files changed, 17 insertions(+), 29 deletions(-) > > diff --git a/mm/list_lru.c b/mm/list_lru.c > index 9d9ec8661354..4c619857e916 100644 > --- a/mm/list_lru.c > +++ b/mm/list_lru.c > @@ -405,35 +405,16 @@ static void memcg_reparent_list_lru_node(struct list_lru *lru, int nid, > spin_unlock_irq(&nlru->lock); > } > > -static void memcg_reparent_list_lru(struct list_lru *lru, > - int src_idx, struct mem_cgroup *dst_memcg) > -{ > - int i; > - > - for_each_node(i) > - memcg_reparent_list_lru_node(lru, i, src_idx, dst_memcg); > - > - memcg_list_lru_free(lru, src_idx); > -} > - > void memcg_reparent_list_lrus(struct mem_cgroup *memcg, struct mem_cgroup *parent) > { > struct cgroup_subsys_state *css; > struct list_lru *lru; > - int src_idx = memcg->kmemcg_id; > + int src_idx = memcg->kmemcg_id, i; > > /* > * Change kmemcg_id of this cgroup and all its descendants to the > * parent's id, and then move all entries from this cgroup's list_lrus > * to ones of the parent. > - * > - * After we have finished, all list_lrus corresponding to this cgroup > - * are guaranteed to remain empty. So we can safely free this cgroup's > - * list lrus in memcg_list_lru_free(). > - * > - * Changing ->kmemcg_id to the parent can prevent memcg_list_lru_alloc() > - * from allocating list lrus for this cgroup after memcg_list_lru_free() > - * call. > */ > rcu_read_lock(); > css_for_each_descendant_pre(css, &memcg->css) { > @@ -444,9 +425,23 @@ void memcg_reparent_list_lrus(struct mem_cgroup *memcg, struct mem_cgroup *paren > } > rcu_read_unlock(); > > + /* > + * With kmemcg_id set to parent, holding the lru lock below can The word of "below" confuses me a bit. "lru lock below" refers to 1) "list_lrus_mutex" or the 2) lock in "struct list_lru_node"? I think it is 2), right? The chnges LGTM. Reviewed-by: Muchun Song Thanks. > + * prevent list_lru_{add,del,isolate} from touching the lru, safe > + * to reparent. > + */ > mutex_lock(&list_lrus_mutex); > - list_for_each_entry(lru, &memcg_list_lrus, list) > - memcg_reparent_list_lru(lru, src_idx, parent); > + list_for_each_entry(lru, &memcg_list_lrus, list) { > + for_each_node(i) > + memcg_reparent_list_lru_node(lru, i, src_idx, parent); > + > + /* > + * Here all list_lrus corresponding to the cgroup are guaranteed > + * to remain empty, we can safely free this lru, any further > + * memcg_list_lru_alloc() call will simply bail out. > + */ > + memcg_list_lru_free(lru, src_idx); > + } > mutex_unlock(&list_lrus_mutex); > } > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 71fe2a95b8bd..fc35c1d3f109 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -4187,13 +4187,6 @@ static void memcg_offline_kmem(struct mem_cgroup *memcg) > parent = root_mem_cgroup; > > memcg_reparent_objcgs(memcg, parent); > - > - /* > - * After we have finished memcg_reparent_objcgs(), all list_lrus > - * corresponding to this cgroup are guaranteed to remain empty. > - * The ordering is imposed by list_lru_node->lock taken by > - * memcg_reparent_list_lrus(). > - */ > memcg_reparent_list_lrus(memcg, parent); > } > #else