Thread (23 messages) 23 messages, 4 authors, 2021-07-13

Re: [External] [PATCH v2 07/14] mm/hugetlb_vmemmap: move comment block to Documentation/vm

From: Mike Kravetz <hidden>
Date: 2021-07-13 00:14:33
Also in: linux-doc, nvdimm

On 6/21/21 6:42 AM, Joao Martins wrote:
On 6/21/21 2:12 PM, Muchun Song wrote:
quoted
On Fri, Jun 18, 2021 at 2:46 AM Joao Martins [off-list ref] wrote:
quoted
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 <redacted>
Cc: Mike Kravetz <redacted>
Suggested-by: Dan Williams <redacted>
Signed-off-by: Joao Martins <redacted>
---
 Documentation/vm/compound_pagemaps.rst | 170 +++++++++++++++++++++++++
 Documentation/vm/index.rst             |   1 +
 mm/hugetlb_vmemmap.c                   | 162 +----------------------
 3 files changed, 172 insertions(+), 161 deletions(-)
 create mode 100644 Documentation/vm/compound_pagemaps.rst
IMHO, how about the name of vmemmap_remap.rst? page_frags.rst seems
to tell people it's about the page mapping not its vmemmap mapping.
Good point.

FWIW, I wanted to avoid the use of the word 'remap' solely because that might be
implementation specific e.g. hugetlbfs remaps struct pages, whereas device-dax will
populate struct pages already with the tail dedup.

Me using 'compound_pagemaps' was short of 'compound struct page map' or 'compound vmemmap'.

Maybe one other alternative is 'tail_dedup.rst' or 'metadata_dedup.rst' ? That's probably
more generic to what really is being done.

Regardless, I am also good with 'vmemmap_remap.rst' if that's what folks prefer.
How about vmemmap_dedup?

I do think it is a good idea to move this to a common documentation file
if Device DAX is going to use the same technique.
-- 
Mike Kravetz
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help