On 6/21/21 6:42 AM, Joao Martins wrote: > On 6/21/21 2:12 PM, Muchun Song wrote: >> On Fri, Jun 18, 2021 at 2:46 AM Joao Martins <joao.m.mart...@oracle.com> >> wrote: >>> >>> 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 <songmuc...@bytedance.com> >>> Cc: Mike Kravetz <mike.krav...@oracle.com> >>> Suggested-by: Dan Williams <dan.j.willi...@intel.com> >>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com> >>> --- >>> 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
