On Fri, Aug 14, 2020 at 06:40:20PM +0100, Matthew Wilcox wrote: > On Fri, Aug 14, 2020 at 10:31:24AM -0700, Minchan Kim wrote: > > There is a need for special HW to require bulk allocation of > > high-order pages. For example, 4800 * order-4 pages. > > ... but you haven't shown that user. Kyoungho is working on it. I am not sure how much he could share but hopefully, he could show some. Kyoungho? > > > int alloc_pages_bulk(unsigned long start, unsigned long end, > > unsigned int migratetype, gfp_t gfp_mask, > > unsigned int order, unsigned int nr_elem, > > struct page **pages); > > > > It will investigate the [start, end) and migrate movable pages > > out there by best effort(by upcoming patches) to make requested > > order's free pages. > > > > The allocated pages will be returned using pages parameter. > > Return value represents how many of requested order pages we got. > > It could be less than user requested by nr_elem. > > I don't understand why a user would need to know the PFNs to allocate > between. This seems like something that's usually specified by GFP_DMA32 > or similar. I wanted to let the API wok from CMA area and/or movable zone where are always fulled with migrable pages. If we carry on only zone flags without pfn range, it couldn't fulfil cma area cases. Other reason is if user see fewer pages returned, he could try subsequent ranges to get remained ones. > Is it useful to return fewer pages than requested? It's useful because user could ask further than what they need or retry.
