All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Zi Yan <ziy@nvidia.com>
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: Wed, 5 Aug 2026 11:52:31 +0100	[thread overview]
Message-ID: <anMVxagM7db3cT_Q@lucifer> (raw)
In-Reply-To: <DKFEUPDED2AF.22PKCFTWTG6G5@nvidia.com>

On Mon, Aug 03, 2026 at 11:23:39AM -0400, Zi Yan wrote:
> 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();

Well these 'post' functions are a bit confusing so I guess I'd say experiment
with different approaches and see which ones end up with the nicest code :)

>
>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo


  parent reply	other threads:[~2026-08-05 10:52 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
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) [this message]
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=anMVxagM7db3cT_Q@lucifer \
    --to=ljs@kernel.org \
    --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=nico.pache@linux.dev \
    --cc=ryan.roberts@arm.com \
    --cc=usama.arif@linux.dev \
    --cc=william.kucharski@oracle.com \
    --cc=willy@infradead.org \
    --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 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.