Thread (38 messages) 38 messages, 9 authors, 2026-01-23

Re: [PATCH v6 1/5] mm/zone_device: Reinitialize large zone device private folios

From: Zi Yan <ziy@nvidia.com>
Date: 2026-01-21 03:01:31
Also in: amd-gfx, dri-devel, intel-xe, kvm, linux-cxl, linux-mm, lkml, nouveau

On 20 Jan 2026, at 8:53, Jason Gunthorpe wrote:
On Mon, Jan 19, 2026 at 09:50:16PM -0500, Zi Yan wrote:
quoted
quoted
quoted
I suppose we want some prep_single_page(page) and some reorg to share
code with the other prep function.
This is just an unnecessary need due to lack of knowledge of/do not want
to investigate core MM page and folio initialization code.
It will be better to keep this related code together, not spread all
around.
Or clarify what code is for preparing pages, which would go away at memdesc
time, and what code is for preparing folios, which would stay.
quoted
quoted
quoted
I don't think so. It should do the above job efficiently and iterate
over the page list exactly once.
folio initialization should not iterate over any page list, since folio is
supposed to be treated as a whole instead of individual pages.
The tail pages need to have the right data in them or compound_head
won't work.
That is done by set_compound_head() in prep_compound_tail().
prep_compound_page() take cares of it. As long as it is called, even if
the pages in that compound page have random states before, the compound
page should function correctly afterwards.
quoted
folio->mapping = NULL;
folio->memcg_data = 0;
folio->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;

should be enough.
This seems believable to me for setting up an order 0 page.
It works for any folio, regardless of its order. fields used in second
or third subpages are all taken care of by prep_compound_page().
quoted
if (order)
	folio_set_large_rmappable(folio);
That one is in zone_device_folio_init()
Yes. And the code location looks right to me.
And maybe the naming has got really confused if we have both functions
now :\
Yes. One of the issues is that device private code used to only handles
order-0 pages and was converted to use high order folio directly without
using high order page (namely compound page) as an intermediate step.
This two-step-in-one caused confusion. But the key thing to avoid the
confusion is that to form a high order folio, a list of contiguous pages
would become a compound page by calling prep_compound_page(), then
the compound page becomes a folio by calling folio_set_large_rmappable().

BTW, the code in prep_compound_head() after folio_set_order(folio, order)
should belong to folio_set_large_rmappable() and they are causing confusion,
since they are only applicable to rmappable large folios. I am going to
send a patch to fix it.


Best Regards,
Yan, Zi
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help