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

On Thu, Feb 24, 2022 at 3:48 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 sk

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

On Thu, Feb 24, 2022 at 3:48 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

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

On Thu, Feb 24, 2022 at 3:48 AM Joao Martins wrote: > > In preparation for describing a memmap with compound pages, move the > actual pte population logic into a separate function > vmemmap_populate_address() and have vmemmap_populate_basepages() walk > through all base pages it needs to populate.

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

On Thu, Feb 24, 2022 at 3:48 AM Joao Martins wrote: > > 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 t

[PATCH v6 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 v6 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 v6 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 v6 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 vmemmap_populate_basepages() walk through all base pages it needs to populate. While doing that, change the helper to use a pte_t* as return

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

Changes since v5[5]: Comments from Muchun Song, * Rebase to next-20220217. * Switch vmemmap_populate_address() to return a pte_t* rather than hardcoded errno value. (Muchun, Patch 2) * Switch vmemmap_populate_compound_pages() to only use pte_t* reflecting previous patch change. Simplifies

[PATCH v6 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