On 2022/7/11 13:51, HORIGUCHI NAOYA(堀口 直也) wrote: > On Mon, Jul 11, 2022 at 11:26:34AM +0800, Miaohe Lin wrote: >> On 2022/7/8 13:36, Naoya Horiguchi wrote: <snip> >> This patch looks good to me with below several possible problems: >> >> Should "nr_huge_pages" and "nr_huge_pages_node" be adjusted too? If it's called from dissolve_free_huge_page >> and hugetlb_vmemmap_restore fails, add_hugetlb_page will be called: >> >> add_hugetlb_page: >> ... >> h->nr_huge_pages++; >> h->nr_huge_pages_node[nid]++; >> ^^^^^^^^1. the "nr_huge_pages" and "nr_huge_pages_node" might be incorrect? >> ... >> zeroed = put_page_testzero(page); >> ^^^^^^^^2. VM_BUG_ON_PAGE(page_ref_count(page) == 0, page); will be triggered? >> >> Or am I miss something? > > No, this code breaks the specific case, so I'd like to simply drop this if. > HPageRawHwpUnreliable hugepage should be very rare, and calling page_mapped() > for such a leaked page should be less common, so the impact of the slowdown > should be minimal. It makes sense for me to drop this if block. Thanks. > > Thanks, > Naoya Horiguchi >
