All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: Qinyun Tan <qinyuntan@linux.alibaba.com>,
	 Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Lance Yang <lance.yang@linux.dev>, Qi Zheng <qi.zheng@linux.dev>,
	 Roman Gushchin <roman.gushchin@linux.dev>,
	Muchun Song <muchun.song@linux.dev>,
	 Dave Chinner <david@fromorbit.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	 David Hildenbrand <david@kernel.org>,
	Xunlei Pang <xlpang@linux.alibaba.com>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers
Date: Wed, 2 Sep 2026 19:17:27 +0200	[thread overview]
Message-ID: <aphXPCn8isUVV87k@localhost.localdomain> (raw)
In-Reply-To: <20260901115104.2944996-1-qinyuntan@linux.alibaba.com>

[-- Attachment #1: Type: text/plain, Size: 2233 bytes --]

Hello Qinyun.

On Tue, Sep 01, 2026 at 07:51:04PM +0800, Qinyun Tan <qinyuntan@linux.alibaba.com> wrote:
> With cgroup.memory=nokmem, shrinker_memcg_alloc() fails with -ENOSYS
> for shrinkers without SHRINKER_NONSLAB, and shrinker_alloc() falls
> back to a non-memcg-aware shrinker.  On this fallback path,
> shrinker->id is never assigned and keeps 0 from kzalloc(), which is a
> valid id belonging to whichever memcg-aware shrinker registers first.
> 
> __list_lru_init() copies shrinker->id unconditionally, so every
> list_lru backed by such a fallback shrinker (thp-deferred_split,
> zswap-shrinker, workingset shadow nodes, superblock lrus, ...) ends
> up with lru->shrinker_id == 0 instead of -1.

<del>thp-deferred_split shrinek has SHRINKER_NONSLAB so, the id should be
assigned (at least I see it in thp_shrinker_init()).</del> I was looking
at 6.12 kernel.

> Under nokmem the list_lru collapses to the shared per-node lists, but
> __list_lru_add() still calls set_shrinker_bit() against the memcg of
> the added object.  Most list_lru users are unaffected because their
> objects resolve to a NULL memcg without kmem accounting, but the THP
> deferred split queue holds user folios, which are charged regardless
> of nokmem.  Since no memcg-aware shrinker can register under nokmem,

Not sure I understand here, the SHRINKER_NONSLAB are excluded and should
still register for per-memcg info.

> shrinker_nr_max stays 0 and every memcg's shrinker_info has
> map_nr_max == 0, so the first folio added by khugepaged triggers on
> every boot:
> 
>   WARNING: mm/shrinker.c:212 at set_shrinker_bit+0x99/0xa0
> 
> On systems where a SHRINKER_NONSLAB shrinker (btrfs, xfs) did register
> and expand the maps, there is no warning; instead bit 0 is set
> spuriously for an unrelated shrinker.

Could it be that you see this issue because of a shrinker which isn't
marked as SHRINKER_NONSLAB?

I'd even go as far as pointing at
fafaeceb89a5e ("mm: switch deferred split shrinker to list_lru")
which removed the flag from the the thp-deferred_split shrinker.

IOW, the proper fix should be addition of SHRINKER_NONSLAB so that
per-memcg maps are properly allocated.

Thanks,
Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

  parent reply	other threads:[~2026-09-02 17:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 11:51 [PATCH] mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers Qinyun Tan
2026-09-01 17:29 ` Andrew Morton
2026-09-02  3:20   ` Qinyun Tan
2026-09-02  2:25 ` Muchun Song
2026-09-02  5:30 ` Baolin Wang
2026-09-02 17:17 ` Michal Koutný [this message]
2026-09-03  4:06   ` Qinyun Tan
2026-09-03  9:20     ` Michal Koutný
2026-09-04  2:10       ` Qinyun Tan
2026-09-04  4:30         ` Andrew Morton
2026-09-03 20:01     ` Andrew Morton
2026-09-04 19:43 ` Wentao Guan

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=aphXPCn8isUVV87k@localhost.localdomain \
    --to=mkoutny@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@fromorbit.com \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=lance.yang@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=qi.zheng@linux.dev \
    --cc=qinyuntan@linux.alibaba.com \
    --cc=roman.gushchin@linux.dev \
    --cc=xlpang@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.