mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>, Qi Zheng <qi.zheng@linux.dev>
Cc: hughd@google.com, baolin.wang@linux.alibaba.com,
	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: Tue, 1 Sep 2026 10:51:58 +0100	[thread overview]
Message-ID: <2638f163-7647-4739-9ee4-5a7e9993455b@linux.dev> (raw)
In-Reply-To: <20260831192143.84da447c4fa2afb60757afa4@linux-foundation.org>



On 01/09/2026 03:21, Andrew Morton wrote:
> On Mon, 31 Aug 2026 10:28:00 +0800 Qi Zheng <qi.zheng@linux.dev> wrote:
> 
>>> 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.
> 
> Thanks.  I pasted this in and turned your [1/4] into a standalone patch
> for mm-hotfixes, with a cc:stable.
> 
> The remaining three patches I turned into a separate series for the
> next merge window.
> 
> This particular patch has no evidence of reviewer input yet?
> 
> 
> From: Qi Zheng <zhengqi.arch@bytedance.com>
> Subject: fs: fix missed removal of super_fs_objects_eligible()
> Date: Mon, 17 Aug 2026 17:03:25 +0800
> 
> 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.
> 
> Link: https://lore.kernel.org/cover.1786955972.git.zhengqi.arch@bytedance.com
> Link: https://lore.kernel.org/3b038d373c70ebac7cdabfb0035bb91d1d6e6cfe.1786955972.git.zhengqi.arch@bytedance.com
> Link: https://lore.kernel.org/all/20260715103516.2410175-1-usama.arif@linux.dev/ [0]
> Fixes: 0ef8faff490b ("fs: push nr_cached_objects memcg gating into individual filesystems")
> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
> Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Muchun Song <muchun.song@linux.dev>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Shakeel Butt <shakeel.butt@linux.dev>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
Yeah unfortunately this was a mess up with a part of the patch not being applied.

Acked-by: Usama Arif <usama.arif@linux.dev>



  parent reply	other threads:[~2026-09-01  9:52 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
2026-09-01  2:21           ` Andrew Morton
2026-09-01  2:25             ` Qi Zheng
2026-09-01  9:51             ` Usama Arif [this message]
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=2638f163-7647-4739-9ee4-5a7e9993455b@linux.dev \
    --to=usama.arif@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=qi.zheng@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

all inboxes | Powered by JetHome®