From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D89638E5C2 for ; Thu, 26 Feb 2026 07:16:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772090195; cv=none; b=OkW6QVPL1sQlrf7GlnMJSz1nbpSzU8hMJwFjnq7U0Bz0gZko2mKxKUvnKo78sCKWCsk3KKd1PNhEKIWrteYwBoW6ZXHnlVkAmAbsC+EfmMZVirFj4vA07grgVo0RAkoVgzEs7Scp33i7U5AyZMJem9v69evj9OU6P5+Zv0yN4b8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772090195; c=relaxed/simple; bh=HOnI0KxJHxODDViMdRa6bFZ3KT9VSSxaD7PLACDcNv4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fA7Ekiwq2pcb7/OS6UZ49CN7ZG3Fn0TKr9GRVbiQ2yx+yNMb/q+dSAT+u2rstIMwoo0bsog6IPHKjuFUHI+8Q3cVbFSMBH9CZm1oYVvKukMVKwjlH84mxKPyJ/j1vn+oz0XghFjphU1oma/ro3oWVH2geKBCH1OYz3M3LwLPyUA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=wJIa/rzI; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="wJIa/rzI" Message-ID: <835ed9a0-da93-4e34-b967-f91954a329b8@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1772090190; 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=mivwzEjvoVllGSbUKSkxFH5flC9gyyg1MxM9PNByEN8=; b=wJIa/rzIJlol6i7Jpp/4hOVMUvSMkMcB8/t2fq8UmOaMSPh6yCohpnIEH6GP7nalM1AOSR zcdYehCNqtbJljqyPEr0akwlCKcuUG53ZM8Ahz0lXQ4vtIxryujMK9GUrFBIuHPfq5MzlH g+vvRC70OajQC8DxtY9m1oOns4Qq72M= Date: Thu, 26 Feb 2026 15:16:13 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] mm: Do not allocate shrinker info with cgroup.memory=nokmem To: =?UTF-8?Q?Michal_Koutn=C3=BD?= , Andrew Morton , Dave Chinner , Qi Zheng , Roman Gushchin , Muchun Song Cc: Jan Kara , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260225-cgroup-ml-nokmem-shrinker-v1-1-d703899bdda4@suse.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: <20260225-cgroup-ml-nokmem-shrinker-v1-1-d703899bdda4@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 2/26/26 2:38 AM, Michal Koutný wrote: > There'd be no work for memcg-aware shrinkers when kernel memory is not > accounted per cgroup, so we can skip allocating per memcg shrinker data. > This saves some memory, avoids holding shrinker_mutex with O(nr_memcgs) > and saves work in shrink_slab_memcg(). > > Then there are SHRINKER_NONSLAB shrinkers which handle non-kernel memory > so nokmem should not disable their per-memcg behavior. Such shrinkers > (e.g. deferred_split_shrinker) still need access to per-memcg data (see > also commit 0a432dcbeb32e ("mm: shrinker: make shrinker not depend on > memcg kmem")). > > The savings with this patch come on container hosts that create many > superblocks (each with own shrinker) but tracking and processing > per-memcg data is pointless with nokmem (shrink_slab_memcg() is > partially guarded with !memcg_kmem_online already). > > The patch uses "boottime" predicate mem_cgroup_kmem_disabled() (not > memcg_kmem_online()) to avoid mistakenly un-MEMCG_AWARE-ing shrinkers > registered before first non-root memcg is mkdir'd. > > Signed-off-by: Michal Koutný > --- > mm/shrinker.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/shrinker.c b/mm/shrinker.c > index 4a93fd433689a..7d7302619b7f7 100644 > --- a/mm/shrinker.c > +++ b/mm/shrinker.c > @@ -219,6 +219,8 @@ static int shrinker_memcg_alloc(struct shrinker *shrinker) > > if (mem_cgroup_disabled()) > return -ENOSYS; > + if (mem_cgroup_kmem_disabled() && !(shrinker->flags & SHRINKER_NONSLAB)) > + return -ENOSYS; Make sense, and can you help update the following comment in shrinker_alloc() as well: /* * The nr_deferred is available on per memcg level for memcg aware * shrinkers, so only allocate nr_deferred in the following cases: * - non-memcg-aware shrinkers * - !CONFIG_MEMCG * - memcg is disabled by kernel command line */ Otherwise: Acked-by: Qi Zheng Thanks, Qi > > mutex_lock(&shrinker_mutex); > id = idr_alloc(&shrinker_idr, shrinker, 0, 0, GFP_KERNEL); > > --- > base-commit: cd2e103d57e5615f9bb027d772f93b9efd567224 > change-id: 20260225-cgroup-ml-nokmem-shrinker-7da42fbcf8f2 > > Best regards,