On 5/6/21 9:05 AM, Aneesh Kumar K.V wrote:
IIUC this series is about devdax namespace with aligh of 1G or 2M where we can
save the vmmemap space by not allocating memory for tail struct pages?
Right.
It reuses base pages across the vmemmap, but for the base pages containing
only the tail struct pages.
Dan Williams [off-list ref] writes:
quoted
quoted
enum:
quoted
enum devmap_geometry {
DEVMAP_PTE,
DEVMAP_PMD,
DEVMAP_PUD,
}
I suppose a converter between devmap_geometry and page_size would be needed too? And maybe
the whole dax/nvdimm align values change meanwhile (as a followup improvement)?
I think it is ok for dax/nvdimm to continue to maintain their align
value because it should be ok to have 4MB align if the device really
wanted. However, when it goes to map that alignment with
memremap_pages() it can pick a mode. For example, it's already the
case that dax->align == 1GB is mapped with DEVMAP_PTE today, so
they're already separate concepts that can stay separate.
devdax namespace with align of 1G implies we expect to map them with 1G
pte entries? I didn't follow when you say we map them today with
DEVMAP_PTE entries.
This sort of confusion is largelly why Dan is suggesting a @geometry for naming rather
than @align (which traditionally refers to page tables entry sizes in pagemap-related stuff).
DEVMAP_{PTE,PMD,PUD} refers to the representation of metadata in base pages (DEVMAP_PTE),
compound pages of PMD order (DEVMAP_PMD) or compound pages of PUD order (DEVMAP_PUD).
So, today:
* namespaces with align of 1G would use *struct pages of order-0* (DEVMAP_PTE) backed with
PMD entries in the direct map.
* namespaces with align of 2M would use *struct pages of order-0* (DEVMAP_PTE) backed with
PMD entries in the direct map.
After this series:
* namespaces with align of 1G would use *compound struct pages of order-30* (DEVMAP_PUD)
backed with PMD entries in the direct map.
* namespaces with align of 1G would use *compound struct pages of order-21* (DEVMAP_PMD)
backed with PTE entries in the direct map.