On 9/15/20 5:59 AM, Muchun Song wrote: > Hi all, > > This patch series will free some vmemmap pages(struct page structures) > associated with each hugetlbpage when preallocated to save memory. ... > The mapping of the first page(index 0) and the second page(index 1) is > unchanged. The remaining 6 pages are all mapped to the same page(index > 1). So we only need 2 pages for vmemmap area and free 6 pages to the > buddy system to save memory. Why we can do this? Because the content > of the remaining 7 pages are usually same except the first page. > > When a hugetlbpage is freed to the buddy system, we should allocate 6 > pages for vmemmap pages and restore the previous mapping relationship. > > If we uses the 1G hugetlbpage, we can save 4095 pages. This is a very > substantial gain. On our server, run some SPDK applications which will > use 300GB hugetlbpage. With this feature enabled, we can save 4797MB > memory. At a high level this seems like a reasonable optimization for hugetlb pages. It is possible because hugetlb pages are 'special' and mostly handled differently than pages in normal mm paths. The majority of the new code is hugetlb specific, so it should not be of too much concern for the general mm code paths. I'll start looking closer at the series. However, if someone has high level concerns please let us know. The only 'potential' conflict I am aware of is discussion about support of double mapping hugetlb pages. https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg02407.html More care/coordination would be needed to support double mapping with this new option. However, this series provides a boot option to disable freeing of unneeded page structs. -- Mike Kravetz
