From: "Zi Yan" <ziy@nvidia.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Matthew Wilcox" <willy@infradead.org>,
"William Kucharski" <william.kucharski@oracle.com>,
"David Hildenbrand" <david@kernel.org>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
"Nico Pache" <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Dev Jain" <dev.jain@arm.com>, "Barry Song" <baohua@kernel.org>,
"Lance Yang" <lance.yang@linux.dev>,
"Usama Arif" <usama.arif@linux.dev>,
<linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<linux-mm@kvack.org>
Subject: Re: [PATCH v2 1/2] mm/huge_memory: use folio's memcg inside __folio_split()
Date: Mon, 03 Aug 2026 11:23:39 -0400 [thread overview]
Message-ID: <DKFEUPDED2AF.22PKCFTWTG6G5@nvidia.com> (raw)
In-Reply-To: <anCtxQE5hDUH5N6a@lucifer>
On Mon Aug 3, 2026 at 11:07 AM EDT, Lorenzo Stoakes (ARM) wrote:
> On Mon, Aug 03, 2026 at 11:02:30AM -0400, Zi Yan wrote:
>> On Sat Aug 1, 2026 at 5:36 AM EDT, Lorenzo Stoakes (ARM) wrote:
>> > On Thu, Jul 30, 2026 at 10:18:00PM -0400, Zi Yan wrote:
>> >> During a pagecache folio split, an xarray node allocation can happen and
>> >> needs to charge at folio's memcg instead of folio split invoker's memcg,
>> >> because for example folio split can happen during reclaim and reclaim's
>> >> active memcg might not be folio's memcg. Switch to folio's memcg at the
>> >> beginning and switch back afterwards.
>> >
>> > I assume this is the only allocation? I guess in general it makes sense to have
>> > the folio's memcg be active here regardless.
>> >
>> >>
>> >> Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
>> >> Fixes: 6b24ca4a1a8d4 ("mm: Use multi-index entries in the page cache")
>> >
>> > Cc: stable?
>>
>> Like you said above, only xas_split_alloc() is affected. And we have not
>> seen related workingset regression report (like what Johannes reported
>> in commit 7b785645e8f13 ("mm: fix page cache convergence regression")).
>> It might be OK to not backport.
>>
>> Johannes, what is your take on this?
>>
>> >
>> >> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> >
>> > Change seems reasonable overall.
>> >
>> > Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>> >
>> >> ---
>> >> mm/huge_memory.c | 20 ++++++++++++++++----
>> >> 1 file changed, 16 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> >> index 04e8a6b553435..b9c2d8908e564 100644
>> >> --- a/mm/huge_memory.c
>> >> +++ b/mm/huge_memory.c
>> >> @@ -4063,34 +4063,42 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
>> >> XA_STATE(xas, &folio->mapping->i_pages, folio->index);
>> >> struct folio *end_folio = folio_next(folio);
>> >> bool is_anon = folio_test_anon(folio);
>> >> + struct mem_cgroup *memcg, *old_memcg;
>> >> struct address_space *mapping = NULL;
>> >> struct anon_vma *anon_vma = NULL;
>> >> int old_order = folio_order(folio);
>> >> struct folio *new_folio, *next;
>> >> int nr_shmem_dropped = 0;
>> >> enum ttu_flags ttu_flags = 0;
>> >> - int ret;
>> >> pgoff_t end = 0;
>> >> + int ret;
>> >>
>> >> VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio);
>> >> VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
>> >>
>> >> if (folio != page_folio(split_at) || folio != page_folio(lock_at)) {
>> >> ret = -EINVAL;
>> >> - goto out;
>> >> + goto out_no_memcg;
>> >> }
>> >>
>> >> if (new_order >= old_order) {
>> >> ret = -EINVAL;
>> >> - goto out;
>> >> + goto out_no_memcg;
>> >> }
>> >>
>> >> ret = folio_check_splittable(folio, new_order, split_type);
>> >> if (ret) {
>> >> VM_WARN_ONCE(ret == -EINVAL, "Tried to split an unsplittable folio");
>> >> - goto out;
>> >> + goto out_no_memcg;
>> >
>> > This function really badly needs splitting up and probably some cleanup.h work :)
>>
>> You mean folio_check_splittable()? You want to move -EINVAL checks a
>> separate one?
>
> No __folio_split().
>
> Comment about cleanup.h really was the whole pattern of goto xxx for various
> levels of unwinding things.
>
> But really I mean the folio splitting code in general, there's a lot of
> massive-complicated-functions with a million things going on at once,
> __folio_freeze_and_split_unmapped() is another.
>
> Feels like we should really have this stuff in something like mm/folio.c anyway
> too now that's renamed :)
>
I agree that __folio_split() is handling multiple cases, anon, shmem,
pagecache, all together. Do you prefer:
1. split __folio_split() to handle each case in a separate function with
some code duplication, like xarray for pagecache and shmem,
freeze/unfreeze folio for all;
or
2. encapulate per-case code in small functions, like
if (is_anon)
split_prepare_anon();
else
split_prepare_file_backed();
__folio_freeze_and_split_unmapped();
if (is_anon)
post_split_anon();
else
post_split_file_backed();
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-08-03 15:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 2:17 [PATCH v2 0/2] Honor XA_FLAGS_ACCOUNT in xas_split_alloc() and charge to folio's memcg Zi Yan
2026-07-31 2:18 ` [PATCH v2 1/2] mm/huge_memory: use folio's memcg inside __folio_split() Zi Yan
2026-08-01 6:57 ` Johannes Weiner
2026-08-01 9:36 ` Lorenzo Stoakes (ARM)
2026-08-03 15:02 ` Zi Yan
2026-08-03 15:07 ` Lorenzo Stoakes (ARM)
2026-08-03 15:23 ` Zi Yan [this message]
2026-08-03 17:25 ` Kairui Song
2026-08-03 17:55 ` Zi Yan
2026-08-04 3:09 ` Kairui Song
2026-08-05 14:36 ` Zi Yan
2026-08-05 10:52 ` Lorenzo Stoakes (ARM)
2026-08-04 20:47 ` Johannes Weiner
2026-08-04 21:27 ` Andrew Morton
2026-08-03 2:39 ` Baolin Wang
2026-07-31 2:18 ` [PATCH v2 2/2] xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc() Zi Yan
2026-08-01 6:58 ` Johannes Weiner
2026-08-01 9:38 ` Lorenzo Stoakes (ARM)
2026-08-03 15:12 ` Zi Yan
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=DKFEUPDED2AF.22PKCFTWTG6G5@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=william.kucharski@oracle.com \
--cc=willy@infradead.org \
/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.