On 3/4/22 03:09, Muchun Song wrote: > On Fri, Mar 4, 2022 at 5:33 AM Joao Martins <[email protected]> wrote: >> A compound devmap is a dev_pagemap with @vmemmap_shift > 0 and it >> means that pages are mapped at a given huge page alignment and utilize >> uses compound pages as opposed to order-0 pages. >> >> Take advantage of the fact that most tail pages look the same (except >> the first two) to minimize struct page overhead. Allocate a separate >> page for the vmemmap area which contains the head page and separate for >> the next 64 pages. The rest of the subsections then reuse this tail >> vmemmap page to initialize the rest of the tail pages. >> >> Sections are arch-dependent (e.g. on x86 it's 64M, 128M or 512M) and >> when initializing compound devmap with big enough @vmemmap_shift (e.g. >> 1G PUD) it may cross multiple sections. The vmemmap code needs to >> consult @pgmap so that multiple sections that all map the same tail >> data can refer back to the first copy of that data for a given >> gigantic page. >> >> On compound devmaps with 2M align, this mechanism lets 6 pages be >> saved out of the 8 necessary PFNs necessary to set the subsection's >> 512 struct pages being mapped. On a 1G compound devmap it saves >> 4094 pages. >> >> Altmap isn't supported yet, given various restrictions in altmap pfn >> allocator, thus fallback to the already in use vmemmap_populate(). It >> is worth noting that altmap for devmap mappings was there to relieve the >> pressure of inordinate amounts of memmap space to map terabytes of pmem. >> With compound pages the motivation for altmaps for pmem gets reduced. >> >> Signed-off-by: Joao Martins <[email protected]> > > Reviewed-by: Muchun Song <[email protected]>
Thank you!
