On 9/29/26 10:22, Muchun Song wrote: > > >> On Sep 29, 2026, at 15:30, David Hildenbrand (Arm) <[email protected]> wrote: >> >> On 9/27/26 04:54, Muchun Song wrote: >>> Device DAX can use vmemmap optimization only when a full section is >>> populated with a compound-page geometry. Record that geometry as the >>> compound page order in section metadata before populating the section, so >>> later vmemmap accounting and population decisions can use the section state >>> directly. >>> >>> Clear the compound page order when the section becomes empty again. Also >>> reject partial additions to a section that already has optimized vmemmap >>> mappings. compound_nr_pages() determines how many struct pages to >>> initialize with a section as the smallest granularity. A section therefore >>> cannot safely mix optimized and ordinary vmemmap layouts. >>> >>> Partial additions continue to use ordinary vmemmap population, so they do >>> not save vmemmap memory. Such additions are uncommon, and the lost saving >>> is negligible. >>> >>> Signed-off-by: Muchun Song <[email protected]> >>> Acked-by: Qi Zheng <[email protected]> >>> --- >>> v3: >>> - Update the subject and commit message to use compound page order >>> terminology >>> - Use EOPNOTSUPP instead of ENOTSUPP >>> >>> v2: >>> - Explain why optimized and ordinary layouts cannot share a section >>> (suggested by Qi Zheng) >>> - Collect Acked-by from Qi Zheng >>> --- >> >> [...]> >>> static struct page * __meminit section_activate(int nid, unsigned long pfn, >>> @@ -838,8 +840,13 @@ static struct page * __meminit section_activate(int >>> nid, unsigned long pfn, >>> struct mem_section *ms = __pfn_to_section(pfn); >>> struct mem_section_usage *usage = NULL; >>> struct page *memmap; >>> + unsigned int order; >>> int rc; >>> >>> + order = vmemmap_can_optimize(altmap, pgmap) ? pgmap->vmemmap_shift : 0; >>> + if (nr_pages < PAGES_PER_SECTION && section_compound_order(ms)) >>> + return ERR_PTR(-EOPNOTSUPP); >> >> Hm. Why should we support optimizing the vmemmap in case we fall into the >> same >> memory section as boot memory? >> >> In that case, there already is a memmap allocated during boot for the entire >> section. IOW, we really shouldn't mess with the vmemmap in case we have an >> early >> section. >> >> But maybe I am missing something and this is already disallowed? > > Yes, this is already handled. > > For a partial addition to a normal early section, after updating the > subsection map we return the existing boot-time memmap here: > > if (nr_pages < PAGES_PER_SECTION && early_section(ms)) > return pfn_to_page(pfn); > > Therefore, neither section_set_compound_order_range() nor > populate_section_memmap() is called. The fully populated boot memmap is > simply reused, and no vmemmap optimization is attempted.
Perfect, thanks Acked-by: David Hildenbrand (Arm) <[email protected]> -- Cheers, David
