Re: [PATCH v6 1/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <[email protected]> |
On 8/6/26 11:52, Liu, Yuan1 wrote: >> -----Original Message----- >> From: David Hildenbrand (Arm) <[email protected]> >> Sent: Thursday, August 6, 2026 4:46 PM >> To: Liu, Yuan1 <[email protected]>; Oscar Salvador <[email protected]>; >> Mike Rapoport <[email protected]>; Wei Yang <[email protected]> >> Cc: [email protected]; Zou, Nanhai <[email protected]>; Deng, Pan >> <[email protected]>; Li, Tianyou <[email protected]>; Chen Zhang >> <[email protected]>; Zeng, Jason <[email protected]>; linux- >> [email protected] >> Subject: Re: [PATCH v6 1/2] mm/memory_hotplug: optimize zone contiguous >> check when changing pfn range >> >> >>> >>> Will do. >>> >>> >>> pages_with_online_memmap counts all PFNs where pfn_to_online_page() is >>> valid. With CONFIG_SPARSEMEM_VMEMMAP, pfn_section_valid() operates at >>> PAGES_PER_SUBSECTION granularity — when any page in a subsection has >>> memory, the entire subsection is valid/online. So we align to subsection >>> boundaries to include hole pages within partially-populated subsections. >> >> But we must never account exceeding the zone range. So I don't understand >> why we >> would have to care about PAGES_PER_SUBSECTION here at all? > > We never account beyond the zone range, because `sub_start` and > `sub_end` are still clamped to the zone boundaries after the > alignment. > > The subsection alignment is needed for hole PFNs between memblocks > within the zone. These hole PFNs are valid for > `pfn_to_online_page()`, because they sit in a subsection that has > memory, so the whole subsection's memmap is online. > > |----------- zone range -----------| > > +-----------+---------+------------+ > + memblock 1| hole | memblock 2 | > +-----------+---------+------------+ > ^ > | > | > subsection boundary Right, but init_unavailable_range() can just return how many were actually initalized? Why can't we piggy-back on that? I think we had something similar previously, why can't we use that? We know the zone span, so we can just account all the mmap in the zone span that we initialize. What is the problem with that? -- Cheers, David