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
