Re: [PATCH v3 3/3] mm: shmem: make unused huge shrinker memcg aware
Qi Zheng <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <[email protected]> |
On 8/6/26 1:35 PM, Baolin Wang wrote: > > > On 8/3/26 4:46 PM, Qi Zheng wrote: >> From: Qi Zheng <[email protected]> >> >> 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. >> >> 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 <[email protected]> >> --- > > Apart from the two issues Sashiko pointed out (which you've already > replied to), nothing else jumped out at me. Thanks. Thanks for the review! I will fix those two issues as I replied, and then send out v4.