On Mon, Jun 13, 2022 at 02:35:09PM +0800”, Muchun Song wrote: > It it inconvenient to mention the feature of optimizing vmemmap pages associated > with HugeTLB pages when communicating with others since there is no specific or > abbreviated name for it when it is first introduced. Let us give it a name HVO > (HugeTLB Vmemmap Optimization) from now. > > This commit also updates the document about "hugetlb_free_vmemmap" by the way > discussed in thread [1]. > > Link: https://lore.kernel.org/all/21aae898-d54d-cc4b-a11f-1bb7fddcfffa@xxxxxxxxxx/ [1] > Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx> > --- > diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst > index a90330d0a837..64e0d5c512e7 100644 > --- a/Documentation/admin-guide/mm/hugetlbpage.rst > +++ b/Documentation/admin-guide/mm/hugetlbpage.rst > @@ -164,8 +164,7 @@ default_hugepagesz > will all result in 256 2M huge pages being allocated. Valid default > huge page size is architecture dependent. > hugetlb_free_vmemmap > - When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables optimizing > - unused vmemmap pages associated with each HugeTLB page. > + When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables HVO. I think we need to define HVO before using it here. Readers may be able to determine the meaning, but to be sure I would suggest: When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set this enables HugeTLB Vmemmap Optimization (HVO). Everything else looks good to me. Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> -- Mike Kravetz
