From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 311B9258CDC for ; Wed, 26 Nov 2025 17:15:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764177322; cv=none; b=aElPiwEdAv9k2qyyldC0dY+2ycgoNir4fA2Giv/q4/9oJd+bqspAyWYiv9HKQr9+74amRB4+xRtyg7sVllDJs8X6IO+vQ7bfcx9CzsCiNLBwYhUyYGUAPDOnfZfM2VPjhDQDC78YQqDksoHKiPEOt0RdLTmnWxA1pVStl3KEZe0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764177322; c=relaxed/simple; bh=qeY9AKlz/m9zjP1bw4AQAIvMyexegtq5Q6XQMc3Nfk4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GGd+VVwL2y2q25PX4Z3DPlZyRdtsS6t//tjJNQqoXmhGeeo1Xx3K9YRmoqLsshUyd2s6HGs1YCs71qJ7X1xeH1ObgY85+3aiX4V+nTcYOLhiShWOS44MA8m4wmVcvYgglBBewaxn9wRWuQAkwWag9NslIg7Dcods73TM8ORv1sM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=M5dnhOEC; arc=none smtp.client-ip=209.85.160.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="M5dnhOEC" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4ed82ee9e57so885151cf.0 for ; Wed, 26 Nov 2025 09:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1764177319; x=1764782119; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Lpxmbrt4LkK+rw3qfn3c0/9obbJZWwIG48frfLdIZ+w=; b=M5dnhOECiLBzdpwVwD5QSXZwCvG3ic5Tcj6XqCvT0gFoUoknt+sivLOuniTsZgshQL 2T/hVHwkXgvkHMrG0ps43VVqheVYM5NXaFhsEMjlNEINaiM1/NYpLLjV82q1CEgZtnEy RB6lQygs2dDMMWsjTVyzZh+L/QO+7ICUUipzRefjv08qxzJJE4d9HxWUF3Zh9U7i9X1L zS0lFIVxSurzqRfVfkemT//7l1rltB6y2I7E/pjQpVNNXabRDJCBX65B4iqjt9fQcNgz eX56ObdKj/dZZq0czr7Z+TKYbJMmaP4tIFf4vEFfVpfyUNo+vIOn7tF5tILuFazLCRdc CZvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764177319; x=1764782119; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Lpxmbrt4LkK+rw3qfn3c0/9obbJZWwIG48frfLdIZ+w=; b=Q8XV7VfGUO/PR0PfKTjM5lBqhVMvjMyfASPveXz/mCOf0IwO5b45A1M92hyWiLkPJV oHd/QGLO7D71S2DqMHWgTPfgYP8B8iWfoIUvRxKAPZEoInhyntEDX21uvAQWXsLBgkov XYDCT+b+dTOSzEDZT7LhcX/Uo29EdyPwbq1VLogbjTzTz6lrd3Gybdxq22C6NL+qEfh3 Czj2fOiI/pPQGiSUVlnR2ARKY/o6vQfa/1w3JdvelZUUeyAu4c3uNa0xdAlwMbXjzb8b pNjtWd5Ea0DdFpcViXNE+9PNYLy1fc5UAedchf1grSiPTj5tynnsCuvFb8UxBrA8evta CP9Q== X-Forwarded-Encrypted: i=1; AJvYcCVn7Z/v7pfJpIppNoigUQ1E9LgNzw+YiQFNR9qzz5BgWscgDBEzCn30NS6FKJXIyjf1Da4tB5neChSotFY=@vger.kernel.org X-Gm-Message-State: AOJu0YxRH62Nx3R0bAbV2NVUKTgXTpp+yem8Hpe5VpPYLIAhtnlSPuqH nPnjMzzCjx0wZ8MpKBCbeH43mpSrlyvYSDNSO4Kbng0gj3xAVNyI628oN5/fo4G6GjI= X-Gm-Gg: ASbGnctz9EwOttdYGnh+YwTDdKXvTdnJEdxwnwDsFcozwD9RzUq6qsurZcowOdKeDkv MHBmaLm92ISgsqMYs3M9U4wgGK+O2bXZCWuNN3vKCorGtzJ251UZwmy3FTzVpPWvrwA40AhCGPh s5PZT3sJeKXAK0Ez2jhCzm7YoZ4HWAAgAoSPkcEd2mhhb630e/sFntrBbzfVIgW6Iv/pbVpibZH Es6NHHHllB0bK8XV0UM330dc35XfGBj8Dj3rnXsSwPhDdx2VEUCYgok12SNPxausmguJm7Wj0md 1rg4SpCNsoHIfR4rLiQyTCx1MCkkI9kTt8xZqlq741l97/7Bia92pQYL+UXhEQCmT4G3/JReAD0 E9B2tIOx/JVwET4SokGRzlC2ImV7K3VTc7DtgXy6XGfNmwre5Dswpwl9eIkuTZUar8j5/2LOOlX cmZ95uliNzkQ== X-Google-Smtp-Source: AGHT+IHoA3sAyrb5rSOSbNAy0GUpa+EZOUE6epCLUVEtNZ8+jRubEupGlWruECHL2V437C9dJQpT0A== X-Received: by 2002:a05:622a:d5:b0:4ee:19ba:d778 with SMTP id d75a77b69052e-4ee58ad46f4mr281257171cf.48.1764177317721; Wed, 26 Nov 2025 09:15:17 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8846e445bd4sm147642686d6.10.2025.11.26.09.15.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Nov 2025 09:15:17 -0800 (PST) Date: Wed, 26 Nov 2025 12:15:13 -0500 From: Johannes Weiner To: Chen Ridong Cc: akpm@linux-foundation.org, david@kernel.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, lujialin4@huawei.com, chenridong@huawei.com Subject: Re: [RFC -next] memcg: Optimize creation performance when LRU_GEN is enabled Message-ID: <20251126171513.GC135004@cmpxchg.org> References: <20251119083722.1365680-1-chenridong@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251119083722.1365680-1-chenridong@huaweicloud.com> On Wed, Nov 19, 2025 at 08:37:22AM +0000, Chen Ridong wrote: > From: Chen Ridong > > With LRU_GEN=y and LRU_GEN_ENABLED=n, a performance regression occurs > when creating a large number of memory cgroups (memcgs): > > # time mkdir testcg_{1..10000} > > real 0m7.167s > user 0m0.037s > sys 0m6.773s > > # time mkdir testcg_{1..20000} > > real 0m27.158s > user 0m0.079s > sys 0m26.270s > > In contrast, with LRU_GEN=n, creation of the same number of memcgs > performs better: > > # time mkdir testcg_{1..10000} > > real 0m3.386s > user 0m0.044s > sys 0m3.009s > > # time mkdir testcg_{1..20000} > > real 0m6.876s > user 0m0.075s > sys 0m6.121s > > The root cause is that lru_gen node onlining uses hlist_nulls_add_tail_rcu, > which traverses the entire list to find the tail. This traversal scales > with the number of memcgs, even when LRU_GEN is runtime-disabled. Can you please look into removing the memcg LRU instead? Use mem_cgroup_iter() with a reclaim cookie in shrink_many(), like we do in shrink_node_memcgs(). The memcg LRU is complicated, and it only works for global reclaim; if you have a subtree with a memory.max at the top, it'll go through shrink_node_memcgs() already anyway.