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

[Mike Kravetz <mike.kravetz@oracle.com>]

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@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 <songmuchun@bytedance.com>
>>> Cc: Mike Kravetz <mike.kravetz@oracle.com>
>>> Suggested-by: Dan Williams <dan.j.williams@intel.com>
>>> Signed-off-by: Joao Martins <joao.m.martins@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