Excerpts from Edgecombe, Rick P's message of April 22, 2022 12:29 pm:
> On Fri, 2022-04-22 at 10:12 +1000, Nicholas Piggin wrote:
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index e163372d3967..70933f4ed069 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -2925,12 +2925,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
>> if (nr != nr_pages_request)
>> break;
>> }
>> - } else
>> - /*
>> - * Compound pages required for remap_vmalloc_page if
>> - * high-order pages.
>> - */
>> - gfp |= __GFP_COMP;
>> + }
>>
>> /* High-order pages or fallback path if "bulk" fails. */
>>
>> @@ -2944,6 +2939,13 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
>> page = alloc_pages_node(nid, gfp, order);
>> if (unlikely(!page))
>> break;
>> + /*
>> + * Higher order allocations must be able to be
>> treated as
>> + * indepdenent small pages by callers (as they can
>> with
>> + * small page allocs).
>> + */
>> + if (order)
>> + split_page(page, order);
>>
>> /*
>> * Careful, we allocate and map page-order pages, but
>
> FWIW, I like this direction. I think it needs to free them differently
> though? Since currently assumes they are high order pages in that path.
> I also wonder if we wouldn't need vm_struct->page_order anymore, and
> all the places that would percolates out to. Basically all the places
> where it iterates through vm_struct->pages with page_order stepping.
To respond to this, I do like having the huge page indicator in
/proc/vmallocinfo. Which is really the only use of it. I might just
keep it in for now.
Thanks,
Nick