[PATCHv6 08/17] mm: Make page_zonenum() use head page
Vlastimil Babka
vbabka at suse.cz
Mon Feb 16 03:20:04 PST 2026
On 2/16/26 10:06, David Hildenbrand (Arm) wrote:
> On 2/16/26 00:13, Matthew Wilcox wrote:
>> On Mon, Feb 02, 2026 at 03:56:24PM +0000, Kiryl Shutsemau wrote:
>>> With the upcoming changes to HVO, a single page of tail struct pages
>>> will be shared across all huge pages of the same order on a node. Since
>>> huge pages on the same node may belong to different zones, the zone
>>> information stored in shared tail page flags would be incorrect.
>>>
>>> Always fetch zone information from the head page, which has unique and
>>> correct zone flags for each compound page.
>>
>> You're right that different pages in the same folio can have different
>> zone number. But does it matter ... or to put it another way, why is
>> returning the zone number of the head page the correct way to resolve
>> this?
>
> How can a folio cross zones?
>
> Runtime allocated hugetlb folios from the CMA/buddy (alloc_contig_range)
> definitely fall into a single zone.
>
> So is it about ones allocated early during boot, where, by chance, we
> manage to cross ZONE_NORMAL + ZONE_MOVABLE etc?
>
> I thought that it's also not allowed there, and I wonder whether we
> should disallow it if it's possible.
I would be surprised if things didn't break horribly if we allowed crossing
zones in a single folio. I'd rather not allow it.
(And I still don't like how this patch solves the issue)
>>
>> Arguably, the caller is asking for the zone number of _this page_, and
>> does not care about the zone number of the head page. It would be good
>> to have a short discussion of this in the commit message (but probably
>> not worth putting this in a comment).
>
> Agreed, in particular, if there would be a functional change. So far I
> assumed there would be no such change.
>
> Things like shrink_zone_span() really need to know the zone of that
> page, not the one of the head; unless both fall into the same zone.
>
More information about the linux-riscv
mailing list