On 7/13/21 1:14 AM, Mike Kravetz wrote: > 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.martins@xxxxxxxxxx> 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 <songmuchun@xxxxxxxxxxxxx> >>>> Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx> >>>> Suggested-by: Dan Williams <dan.j.williams@xxxxxxxxx> >>>> Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx> >>>> --- >>>> 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? > Sounds good to me, I'll rename it. > 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. >
