From: Qi Zheng <qi.zheng@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: hughd@google.com, baolin.wang@linux.alibaba.com,
usama.arif@linux.dev, brauner@kernel.org, david@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Qi Zheng <zhengqi.arch@bytedance.com>
Subject: Re: [PATCH v4 1/4] fs: fix missed removal of super_fs_objects_eligible()
Date: Mon, 31 Aug 2026 10:28:00 +0800 [thread overview]
Message-ID: <c1ad6e39-3b21-413c-ad02-f90cfc4102f9@linux.dev> (raw)
In-Reply-To: <20260829162350.1ee9e17d71a297b06b171941@linux-foundation.org>
Hi Andrew,
On 8/30/26 7:23 AM, Andrew Morton wrote:
> On Sat, 29 Aug 2026 09:49:44 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:
>
>> Hi Andrew,
>>
>> On 8/29/26 2:41 AM, Andrew Morton wrote:
>>> On Mon, 17 Aug 2026 17:03:25 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:
>>>
>>>> From: Qi Zheng <zhengqi.arch@bytedance.com>
>>>>
>>>> Commit 0ef8faff490be ("fs: push nr_cached_objects memcg gating into
>>>> individual filesystems") forgot to drop the super_fs_objects_eligible(),
>>>> just fix it.
>>>
>>> Oh. Why? Please can we have a description of what's wrong with the
>>> current code?
>>
>> As I replied in another thread [1], this fix and commit 0ef8faff490be
>> together make up the complete patch originally sent by Usama [2], so
>> they should be squashed together.
>
> 0ef8faff490be is upstream so they can't be squashed!
So sad.
>
>> Without this fix, all memcg-aware
>> nr_cached_objects() will be skipped during memcg-level shrinking.
>> Besides the newly added memcg-aware shmem huge shrinker, XFS will also
>> run into issues.
>
> OK, please add this info to this patch's changelog. Please also decide
> whether a cc:stable should be added and if so, ensure the changelog
> makes clear why we're recommending a backport.
>
> As part of this, let's expand on "XFS will also run into issues".
How about this instead:
---
Commit 0ef8faff490be ("fs: push nr_cached_objects memcg gating into
individual filesystems") was meant to drop the blanket memcg gate in
fs/super.c and let each ->nr_cached_objects() implementation decide
for itself whether it is meaningful in per-memcg reclaim. However,
when that patch was applied the removal of super_fs_objects_eligible()
and its two call sites in super_cache_scan() / super_cache_count() was
lost, so the helper is still gating every ->nr_cached_objects() hook
and 0ef8faff490be is effectively a no-op.
Consequences of the leftover gate:
- XFS's inode-reclaim hook, which is intentionally driven from
per-memcg contexts to free memcg-charged slab, is still
short-circuited in fs/super.c — exactly the regression from
commit 0baad6f9b997 ("fs/super: skip non-memcg-aware
nr_cached_objects in memcg slab shrink") that 0ef8faff490be was
written to undo. Memcg-charged XFS inode slab therefore keeps
piling up under per-memcg pressure until global reclaim kicks in.
- Any future ->nr_cached_objects()/->free_cached_objects() that
grows memcg awareness is likewise blocked before it can run, so
filesystems cannot opt in to per-memcg reclaim on their own —
defeating the whole point of pushing the gating decision down
into the callbacks.
Drop the leftover helper and its call sites so the intent of
0ef8faff490be actually takes effect.
Fixes: 0ef8faff490be ("fs: push nr_cached_objects memcg gating into
individual filesystems")
Cc: stable@vger.kernel.org
---
Can you fix up the commit message directly on your end? Let me know if
you prefer me to spin a v5 instead.
Thank,
Qi
>
> Thanks.
>
next prev parent reply other threads:[~2026-08-31 2:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 9:03 [PATCH v4 0/4] make unused huge shrinker memcg aware Qi Zheng
2026-08-17 9:03 ` [PATCH v4 1/4] fs: fix missed removal of super_fs_objects_eligible() Qi Zheng
2026-08-28 18:41 ` Andrew Morton
2026-08-29 1:49 ` Qi Zheng
2026-08-29 23:23 ` Andrew Morton
2026-08-31 2:28 ` Qi Zheng [this message]
2026-09-01 2:21 ` Andrew Morton
2026-09-01 2:25 ` Qi Zheng
2026-09-01 9:51 ` Usama Arif
2026-08-17 9:03 ` [PATCH v4 2/4] mm: memcontrol: make obj_cgroup_memcg() handle NULL objcg Qi Zheng
2026-08-17 11:29 ` Qi Zheng
2026-08-17 16:05 ` Shakeel Butt
2026-08-17 9:03 ` [PATCH v4 3/4] mm: shmem: move unused huge shrinklist queuing past the truncation check Qi Zheng
2026-08-17 9:03 ` [PATCH v4 4/4] mm: shmem: make unused huge shrinker memcg aware Qi Zheng
2026-08-18 3:54 ` Baolin Wang
2026-08-27 22:50 ` [PATCH v4 0/4] " Andrew Morton
2026-08-28 2:48 ` Qi Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1ad6e39-3b21-413c-ad02-f90cfc4102f9@linux.dev \
--to=qi.zheng@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=david@kernel.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=usama.arif@linux.dev \
--cc=zhengqi.arch@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox