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 E86C0C433F5 for ; Tue, 18 Jan 2022 12:07:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DA926B0075; Tue, 18 Jan 2022 07:07:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 789F06B0078; Tue, 18 Jan 2022 07:07:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6525D6B007B; Tue, 18 Jan 2022 07:07:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 54E576B0075 for ; Tue, 18 Jan 2022 07:07:31 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1F7728F840 for ; Tue, 18 Jan 2022 12:07:31 +0000 (UTC) X-FDA: 79043283102.07.619BC5D Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf15.hostedemail.com (Postfix) with ESMTP id 04939A000C for ; Tue, 18 Jan 2022 12:07:28 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id g81so54995553ybg.10 for ; Tue, 18 Jan 2022 04:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OC5quY8+bzQ7YwLxGQW1P7Vgcog//q1EsjQWuTsPZiA=; b=c3af9NXfUtTV/ISsfNREopmBIAf8fT4PPP17qdILfbQoqvb1yfMa+D0XLlYT6JoNjU ePaLArNrWW5zLYdpo1aCAVvBM7NZdg3qoad2pIpBpn+dKX2qpHWbIzeTo/ZWGlUzG9m6 hdWzHLZgMHYc+km3yxBo/4gsymQJh83zgMLiF405qZowaqIxM7BnTJJFnGp2/q35ZIA6 maVqxHfZSqMXQDeOLAlQCpQMgLny1kM6wpQgjMqc1MgA20REMRU1Kyb60DSCWB1/YGt0 nmM29RNua0k7xFUkauKHhL0GFjcs9AX976BwT6xrQiJmMLPjBfkMK40ffRMoWetReJqm /lFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OC5quY8+bzQ7YwLxGQW1P7Vgcog//q1EsjQWuTsPZiA=; b=SS+ErK5HRk+g3ztb1lAIHxeqNhtHI6W7O1gZ+8rFtqeGH6aPLauOpLkZT6yP7RK5+S NzGmDwqbfllhDatyqzWvEBHrw2bkCVymDGyW0FtHxRBaKu+QI1cStGerowo1dM3l0JCY 5o6A0y/Tzj2fIrbjmZKASkZGDt6mzuv03grrigepiWVIwaRsgO+pvtT6WQAc+iQbYPId CAKa6+rMCZofRTLfAKW2CG61zz19OjGhN8m8zda0J0P1QHQEBlYBQIQT0frJ61lJodw1 5M3TCz/0z6X4hFQSc6LMNgHqF5GvCtiZ7W5wmc5b3rQiDywoE8pjXWhWemlmXx69JHlZ YCCA== X-Gm-Message-State: AOAM533UnzrrtrP3odoiWEMZfItDwxbA7/UK8iPC861ojgJ1kaQX0iZ6 nsSL2aHXG1hNVB1YYxlNh2RtwB6I7P9WKdsYVzm3Jw== X-Google-Smtp-Source: ABdhPJxNFvL/SkKU6juzzW+raWlteR7gaAX3pdOhU7lWwwCB3tPpMz6t5NIUds1vo4+A7k0YLFoYLeZ3JS1yM7GxpMg= X-Received: by 2002:a25:8806:: with SMTP id c6mr31085871ybl.199.1642507648082; Tue, 18 Jan 2022 04:07:28 -0800 (PST) MIME-Version: 1.0 References: <20211220085649.8196-1-songmuchun@bytedance.com> <20211220085649.8196-11-songmuchun@bytedance.com> <20220106110051.GA470@blackbody.suse.cz> <20220113133213.GA28468@blackbody.suse.cz> In-Reply-To: <20220113133213.GA28468@blackbody.suse.cz> From: Muchun Song Date: Tue, 18 Jan 2022 20:05:44 +0800 Message-ID: Subject: Re: [PATCH v5 10/16] mm: list_lru: allocate list_lru_one only when needed To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Matthew Wilcox , Andrew Morton , Johannes Weiner , Michal Hocko , Vladimir Davydov , Shakeel Butt , Roman Gushchin , Yang Shi , Alex Shi , Wei Yang , Dave Chinner , trond.myklebust@hammerspace.com, anna.schumaker@netapp.com, jaegeuk@kernel.org, chao@kernel.org, Kari Argillander , linux-fsdevel , LKML , Linux Memory Management List , linux-nfs@vger.kernel.org, Qi Zheng , Xiongchun duan , Fam Zheng , Muchun Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 04939A000C X-Stat-Signature: uy9hno6atiata3c1dmhrfckdj446wjr7 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=c3af9NXf; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf15.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Rspamd-Server: rspam03 X-HE-Tag: 1642507648-323042 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, Jan 13, 2022 at 9:32 PM Michal Koutn=C3=BD wrote= : > > On Wed, Jan 12, 2022 at 09:22:36PM +0800, Muchun Song wrote: > > root(-1) -> A(0) -> B(1) -> C(2) > > > > CPU0: CPU1: > > memcg_list_lru_alloc(C) > > memcg_drain_all_list_lrus(C) > > memcg_drain_all_list_lrus(B) > > // Now C and B are offline. The > > // kmemcg_id becomes the follow= ing if > > // we do not the kmemcg_id of i= ts > > // descendants in > > // memcg_drain_all_list_lrus(). > > // > > // root(-1) -> A(0) -> B(0) -> = C(1) > > > > for (i =3D 0; memcg; memcg =3D parent_mem_cgroup(memcg), i++) { > > // allocate struct list_lru_per_memcg for memcg C > > table[i].mlru =3D memcg_init_list_lru_one(gfp); > > } > > > > spin_lock_irqsave(&lru->lock, flags); > > while (i--) { > > // here index =3D 1 > > int index =3D table[i].memcg->kmemcg_id; > > > > struct list_lru_per_memcg *mlru =3D table[i].mlru; > > if (index < 0 || rcu_dereference_protected(mlrus->mlru[index], tr= ue)) > > kfree(mlru); > > else > > // mlrus->mlru[index] will be assigned a new value regardless > > // memcg C is already offline. > > rcu_assign_pointer(mlrus->mlru[index], mlru); > > } > > spin_unlock_irqrestore(&lru->lock, flags); > > > > > So changing ->kmemcg_id of all its descendants can prevent > > memcg_list_lru_alloc() from allocating list lrus for the offlined > > cgroup after memcg_list_lru_free() calling. > > Thanks for the illustrative example. I can see how this can be a problem > in a general call of memcg_list_lru_alloc(C). > > However, the code, as I understand it, resolves the memcg to which lru > allocation should be associated via get_mem_cgroup_from_objcg() and > memcg_reparent_list_lrus(C) comes after memcg_reparent_objcgs(C, B), > i.e. the allocation would target B (or even A if after > memcg_reparent_objcgs(B, A))? > > It seems to me like "wasting" the existing objcg reparenting mechanism. > Or what do you think could be a problem relying on it? > I have thought about this. It's a little different to rely on objcg reparenting since the user can get memcg from objcg and then does not realize the memcg has reparented. Although it can check memcg->objcg to know whether the memcg is reparented, it should also prevent this memcg from being reparented throughout memcg_list_lru_alloc(). Maybe holding css_set_lock can do that. I do not think this is a good choice. Do you have any thoughts about this? Thanks.