From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 764843C8700 for ; Tue, 18 Aug 2026 03:54:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787025266; cv=none; b=cLx2+PfAhKXV4a+FWgK2bivbOqguvOtKZccSbwbLaFkwelG6BmvBs5HsWg1mLXvViOVyvWhOZ5R7YRAnDst8iG16oQSfGAyNynhPnfCtn9ETry1ch2hAACNGbTMsD8JRCkEOrIMe9Eg5+iET/4sPtd7JvYyvdPzhMW7DCzsdqmc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787025266; c=relaxed/simple; bh=cKnNceMX7e+caYjNUMwYhkdgTF3gGEHXYJvGG8NrHUY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=b1K5PSDIZEEoClbK1zwEDAAFU+lD6tWxw8fVJIVvt1NqHuT8KxdFwxPGK7VmaL6LrqItS+IwCuG9sqdbLniLcgJUPb1CAigxsvWyzvG+E7ymcA1xPxLO6dxUID71WlCLFm6+EwF/I/1jSFHyOLnWhP4iUzEu8i9Ab4uwOIlSaaE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=MM1BjUNV; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="MM1BjUNV" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787025259; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=VoCWHLN0b2TBHZx2AKnPa0V1F1II07CEG4GPygei01o=; b=MM1BjUNVDNfXUijnjl2SCUnQgMAxMw/gzd+C0lya4GuGQGz/vPj3q7o7CEebQDIsXZmbX0bMhEF8v8b/d11aC8Msen+k6Lrofx7oYrh5s5JJ0IcfDymva7T0tCvhwBq2w1AjA9hxNFF8TWz8I3W7TSCtV1F0QVU+0NiOqch4p0M= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X9BvG2d_1787025258; Received: from 30.74.144.114(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X9BvG2d_1787025258 cluster:ay36) by smtp.aliyun-inc.com; Tue, 18 Aug 2026 11:54:19 +0800 Message-ID: <5e409803-f69e-4f09-bb15-9c2a7e85ac92@linux.alibaba.com> Date: Tue, 18 Aug 2026 11:54:18 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] mm: shmem: make unused huge shrinker memcg aware To: Qi Zheng , hughd@google.com, usama.arif@linux.dev, brauner@kernel.org, akpm@linux-foundation.org, david@kernel.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng References: <94cc7fe1fd645254ae90effc1c0687678438d940.1786955972.git.zhengqi.arch@bytedance.com> From: Baolin Wang In-Reply-To: <94cc7fe1fd645254ae90effc1c0687678438d940.1786955972.git.zhengqi.arch@bytedance.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/17/26 5:03 PM, Qi Zheng wrote: > From: Qi Zheng > > The shmem unused huge shrinker keeps a per-superblock list of inodes whose > tail huge folio extends beyond i_size. Since that list is not memcg aware, > reclaim triggered by one memcg can scan inodes from the whole superblock > and split shmem huge folios charged to unrelated memcgs. > > Convert the shrink list to a memcg-aware list_lru. Queue each inode on the > list_lru sublist matching the memcg and node of the current tail huge > folio, so non-root memcg reclaim only walks candidates charged to the > reclaiming memcg. Global reclaim, root memcg reclaim and shmem quota > reclaim keep global semantics. > > Rather than pinning a struct mem_cgroup reference in shmem_inode_info, > store a struct obj_cgroup reference instead. The list_lru add and delete > paths resolve the current memcg from the objcg under RCU, so that memcg > offline and list_lru entry migration remain consistent: list_lru migrates > entries to the parent memcg sublist on offline, and obj_cgroup_memcg() > follows the same reparenting, ensuring the correct sublist is always found > at delete time. This avoids pinning a dying memcg through a long-lived > CSS reference. > > The list_lru still tracks inodes while the actual split target is the > current tail huge folio, so validate the folio memcg/node during scan. If > the folio no longer matches the reclaim context or splitting cannot > proceed, requeue the inode according to the current tail folio; if the > inode is no longer shrinkable, drop the scan entry. > > This can be tested with the shrinker debugfs interface by allocating 32 > tmpfs tail THPs in each of two memcgs, then scanning the sb-tmpfs shrinker > with memcg A's cgroup id: > > before A scan after A scan > base A=64M, B=64M A=64M, B=64M (per-memcg count is skipped) > patched A=64M, B=64M A=0, B=64M > > Signed-off-by: Qi Zheng > --- Nothing else jumped out at me. Thanks. Reviewed-by: Baolin Wang