Re: [PATCH v7 5/5] mm/page_alloc: reuse tail struct pages for compound devmaps

On Fri, Mar 4, 2022 at 5:33 AM Joao Martins wrote: > > Currently memmap_init_zone_device() ends up initializing 32768 pages > when it only needs to initialize 128 given tail page reuse. That > number is worse with 1GB compound pages, 262144 instead of 128. Update > memmap_init_zone_device() to ski

Re: [PATCH v7 4/5] mm/sparse-vmemmap: improve memory savings for compound devmaps

On Fri, Mar 4, 2022 at 5:33 AM Joao Martins 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 l

[PATCH v7 3/5] mm/hugetlb_vmemmap: move comment block to Documentation/vm

In preparation for device-dax for using hugetlbfs compound page tail deduplication technique, move the comment block explanation into a common place in Documentation/vm. Cc: Muchun Song Cc: Mike Kravetz Suggested-by: Dan Williams Signed-off-by: Joao Martins Reviewed-by: Muchun Song Reviewed-b

[PATCH v7 4/5] mm/sparse-vmemmap: improve memory savings for compound devmaps

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 ove

[PATCH v7 5/5] mm/page_alloc: reuse tail struct pages for compound devmaps

Currently memmap_init_zone_device() ends up initializing 32768 pages when it only needs to initialize 128 given tail page reuse. That number is worse with 1GB compound pages, 262144 instead of 128. Update memmap_init_zone_device() to skip redundant initialization, detailed below. When a pgmap @vme

[PATCH v7 2/5] mm/sparse-vmemmap: refactor core of vmemmap_populate_basepages() to helper

In preparation for describing a memmap with compound pages, move the actual pte population logic into a separate function vmemmap_populate_address() and have a new helper vmemmap_populate_range() walk through all base pages it needs to populate. While doing that, change the helper to use a pte_t*

[PATCH v7 1/5] mm/sparse-vmemmap: add a pgmap argument to section activation

In support of using compound pages for devmap mappings, plumb the pgmap down to the vmemmap_populate implementation. Note that while altmap is retrievable from pgmap the memory hotplug code passes altmap without pgmap[*], so both need to be independently plumbed. So in addition to @altmap, pass @p

[PATCH v7 0/5] sparse-vmemmap: memory savings for compound devmaps (device-dax)

Changes since v6[7]: Comments from Muchun Song, * Add Muchun Reviewed-by in patch 1 and 2 * Rework a tiny bit of patch 2 to introduce vmemmap_populate_range() as a generic helper and have vmemmap_populate_basepages() be based on that -- that removes duplicated code in patch 4. Retained Rb