On 2/23/21 3:21 PM, Mike Kravetz wrote: > On 2/23/21 2:58 PM, Oscar Salvador wrote: >> On 2021-02-23 23:55, Mike Kravetz wrote: >>> Yes, that is the more common case where the once active hugetlb page >>> will be simply added to the free list via enqueue_huge_page(). This >>> path does not go through prep_new_huge_page. >> >> Right, I see. >> >> Thanks > > You got me thinking ... > When we dynamically allocate gigantic pages via alloc_contig_pages, we > will not use the buddy allocator. Therefore, the usual 'page prepping' > will not take place. Specifically, I could not find anything in that > path which clears page->private of the head page. > Am I missing that somewhere? If not, then we need to clear that as well > in prep_compound_gigantic_page. Or, just clear it in prep_new_huge_page > to handle any change in assumptions about the buddy allocator. > > This is not something introduced with the recent field shuffling, it > looks like something that existed for some time. nm, we do end up calling the same page prepping code (post_alloc_hook) from alloc_contig_range->isolate_freepages_range. Just to make sure, I purpously dirtied page->private of every page as it was being freed. Gigantic page allocation was just fine, and I even ran ltp mm tests with this dirtying in place. -- Mike Kravetz
