From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) (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 B4202364929; Tue, 14 Jul 2026 10:18:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784024282; cv=none; b=rQfho5L+7D0dS8KDaE6D8LPMcjiV2Ir3U9/0DbgL91OxsMFZd04jLeyzI54XSMfs1PaJxR0Bbt1EiDlyB2OYPwFbo2qKD7rmUZJgwPdQPfqmRSnBYGvys9XTIsagqFIEWm/tWn112wqE6rxGEsCqy3rAXxPPslZ++Qmc099M2l4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784024282; c=relaxed/simple; bh=Mc8muXwHgWJ3LP8g1wRWeqXEkFLLP6iDZu3v9ZOHf+A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bR4CbCIgDjSSWLD08bHgftLxanXf3+Prp2f5mu7LulG/BH8pneJeY7+wR4TdbHGBYSYZ7xvN//Lw/Cb7uHhwG40NG43zot4ejOhxV4ShoPHzqUvjNp33SdMGiLLBNlNFXm1+V/1vlsxpXl9SxwzZsTg0NWY8HdQPNBL1sc+/TLI= 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=YPQmMD0/; arc=none smtp.client-ip=95.215.58.183 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="YPQmMD0/" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784024278; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EDiZS8zttT4a9O025kBB1zOShFsYsLLFK1SisQ6msEY=; b=YPQmMD0/zTCtgtqVy5SDNK+fsg0BTqTsor+JXyoKqwEfTjG7p9IsJgjJNVeLOLicga3pXM gP9//+7EcPmcJzR94Erhzir6snvi2gfkCwv0wOCWnsrLDd1Hd30WV/lxmMJyKojs/BGpkv I7T1czZ32Ibjv2lEpa1TLNGT4zPUUE8= From: Usama Arif To: Qi Zheng Cc: Usama Arif , brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Al Viro , linux-mm@kvack.org, hughd@google.com, boris@bur.io, clm@fb.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, cem@kernel.org, linux-xfs@vger.kernel.org, shakeel.butt@linux.dev, hannes@cmpxchg.org, riel@surriel.com, kernel-team@meta.com Subject: Re: [PATCH] fs/super: skip non-memcg-aware nr_cached_objects in memcg slab shrink Date: Tue, 14 Jul 2026 03:17:38 -0700 Message-ID: <20260714101740.1270419-1-usama.arif@linux.dev> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Tue, 14 Jul 2026 10:09:26 +0800 Qi Zheng wrote: > Hi Usama, > > On 7/13/26 11:34 PM, Usama Arif wrote: > > > > > > On 13/07/2026 14:12, Qi Zheng wrote: > >> Hi Usama, > >> > >> On 6/9/26 8:30 PM, Usama Arif wrote: > >>> The super_block shrinker is registered with SHRINKER_MEMCG_AWARE because its > >>> dentry and inode LRUs are memcg-aware (via list_lru). But the optional > >>> ->nr_cached_objects() hooks that the shrinker also drives are not memcg-aware: > >>> btrfs extent maps and xfs inode reclaim operate on filesystem-global > >>> state, and shmem's unused-huge shrinker walks a per-superblock shrinklist. > >>> None of them filter by sc->memcg. > >> > >> This makes sense for now, but how should we handle this if these > >> shrinkers are made memcg-aware in the future? > >> > >> I've recently been working on making the shmem huge shrinker > >> memcg-aware, but noticed my changes broke after rebasing onto the latest > >> tree, which led me to this patch. > >> > >> As for the shmem huge shrinker, I can work around this limitation by > >> making it a separate shrinker. But this feels more like an overall > >> design decision, effectively meaning that all nr_cached_objects are > >> precluded from being memcg-aware. > >> > >> Thanks, > >> Qi > >> > > > > > > Hi Qi, > > > > Thanks for raising this. I think the alternative is what I mentioned in > > https://lore.kernel.org/all/cfdb8620-ea55-4226-98bf-d006820e6270@linux.dev/ > > move this down to the fs own callbacks instead of here. Would that > > be better? > > Yes, I think this is a better approach. > > Later on, shrinkers that are converted to be memcg-aware can lift this > restriction themselves. > > Thanks, > Qi Thanks Qi, I have sent a patch to push it down to filesystems in [1]. No functional change inteneded in there. You would have to rebase your patch on top of that one and remove my code in shmem specifically. [1] https://lore.kernel.org/all/20260714101454.1202449-1-usama.arif@linux.dev/ > > > > > Thanks, > > Usama > >