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. Besides fixing the bisected issue (hopefully), it also more cleanly separates the mapping from the backing allocation logic. And then since all the pages are 4k (from the page allocator perspective), it would be easier to support non-huge page aligned sizes. i.e. not use up a whole additional 2MB page if you only need 4k more of allocation size.
