From: Shakeel Butt <shakeel.butt@linux.dev>
To: Zi Yan <ziy@nvidia.com>
Cc: David Hildenbrand <david@redhat.com>,
Qi Zheng <zhengqi.arch@bytedance.com>,
hannes@cmpxchg.org, hughd@google.com, mhocko@suse.com,
roman.gushchin@linux.dev, muchun.song@linux.dev,
lorenzo.stoakes@oracle.com, harry.yoo@oracle.com,
baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com,
npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com,
baohua@kernel.org, lance.yang@linux.dev,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH v2 4/4] mm: thp: reparent the split queue during memcg offline
Date: Thu, 25 Sep 2025 15:35:17 -0700 [thread overview]
Message-ID: <wlbplybaecktirfzygddbvrerzrozzfudlqavkbmhnmoyt6xmf@64ikayr3fdlo> (raw)
In-Reply-To: <tyl5nag4exta7mmxejhzd5xduulfy5pjzde4mpklscqoygkaso@zdyadmle3wjj>
On Thu, Sep 25, 2025 at 03:15:26PM -0700, Shakeel Butt wrote:
> On Thu, Sep 25, 2025 at 03:49:52PM -0400, Zi Yan wrote:
> > On 25 Sep 2025, at 15:35, David Hildenbrand wrote:
> >
> > > On 25.09.25 08:11, Qi Zheng wrote:
> > >> Hi David,
> > >
> > > Hi :)
> > >
> > > [...]
> > >
> > >>>> +++ b/include/linux/mmzone.h
> > >>>> @@ -1346,6 +1346,7 @@ struct deferred_split {
> > >>>> spinlock_t split_queue_lock;
> > >>>> struct list_head split_queue;
> > >>>> unsigned long split_queue_len;
> > >>>> + bool is_dying;
> > >>>
> > >>> It's a bit weird to query whether the "struct deferred_split" is dying.
> > >>> Shouldn't this be a memcg property? (and in particular, not exist for
> > >>
> > >> There is indeed a CSS_DYING flag. But we must modify 'is_dying' under
> > >> the protection of the split_queue_lock, otherwise the folio may be added
> > >> back to the deferred_split of child memcg.
> > >
> > > Is there no way to reuse the existing mechanisms, and find a way to have the shrinker / queue locking sync against that?
> > >
> > > There is also the offline_css() function where we clear CSS_ONLINE. But it happens after calling ss->css_offline(css);
> >
> > I see CSS_DYING will be set by kill_css() before offline_css() is called.
> > Probably the code can check CSS_DYING instead.
> >
> > >
> > > Being able to query "is the memcg going offline" and having a way to sync against that would be probably cleanest.
> >
> > So basically, something like:
> > 1. at folio_split_queue_lock*() time, get folio’s memcg or
> > its parent memcg until there is no CSS_DYING set or CSS_ONLINE is set.
> > 2. return the associated deferred_split_queue.
> >
>
> Yes, css_is_dying() can be used but please note that there is a rcu
> grace period between setting CSS_DYING and clearing CSS_ONLINE (i.e.
> reparenting deferred split queue) and during that period the deferred
> split THPs of the dying memcg will be hidden from shrinkers (which
> might be fine).
BTW if this period is not acceptable and we don't want to add is_dying
to struct deferred_split, we can use something similar to what list_lru
does in the similar situation i.e. set a special value (LONG_MIN) in its
nr_items variable. That is make split_queue_len a long and set it to
LONG_MIN during memcg offlining/reparenting.
next prev parent reply other threads:[~2025-09-25 22:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 9:16 [PATCH v2 0/4] reparent the THP split queue Qi Zheng
2025-09-23 9:16 ` [PATCH v2 1/4] mm: thp: replace folio_memcg() with folio_memcg_charged() Qi Zheng
2025-09-24 9:10 ` Roman Gushchin
2025-09-23 9:16 ` [PATCH v2 2/4] mm: thp: introduce folio_split_queue_lock and its variants Qi Zheng
2025-09-23 9:16 ` [PATCH v2 3/4] mm: thp: use folio_batch to handle THP splitting in deferred_split_scan() Qi Zheng
2025-09-23 15:31 ` Zi Yan
2025-09-24 9:57 ` Qi Zheng
2025-09-24 14:57 ` Zi Yan
2025-09-24 12:31 ` David Hildenbrand
2025-09-23 9:16 ` [PATCH v2 4/4] mm: thp: reparent the split queue during memcg offline Qi Zheng
2025-09-23 15:44 ` Zi Yan
2025-09-24 9:58 ` Qi Zheng
2025-09-24 9:23 ` Roman Gushchin
2025-09-24 10:06 ` Qi Zheng
2025-09-24 12:38 ` David Hildenbrand
2025-09-25 6:11 ` Qi Zheng
2025-09-25 19:35 ` David Hildenbrand
2025-09-25 19:49 ` Zi Yan
2025-09-25 22:15 ` Shakeel Butt
2025-09-25 22:35 ` Shakeel Butt [this message]
2025-09-26 6:57 ` Qi Zheng
2025-09-26 16:36 ` Shakeel Butt
2025-09-24 13:49 ` kernel test robot
2025-09-24 14:22 ` Harry Yoo
2025-09-25 6:29 ` 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=wlbplybaecktirfzygddbvrerzrozzfudlqavkbmhnmoyt6xmf@64ikayr3fdlo \
--to=shakeel.butt@linux.dev \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=cgroups@vger.kernel.org \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=hughd@google.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=npache@redhat.com \
--cc=roman.gushchin@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.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