On Fri, Aug 14, 2020 at 01:55:58PM -0700, Minchan Kim wrote:
On Fri, Aug 14, 2020 at 06:40:20PM +0100, Matthew Wilcox wrote:
quoted
On Fri, Aug 14, 2020 at 10:31:24AM -0700, Minchan Kim wrote:
quoted
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?
Hyesoo posted a patch series that uses alloc_pages_bulk() in a dma-heap;
please take a look at:
https://lore.kernel.org/linux-mm/20200818080415.7531-1-hyesoo.yu@samsung.com/ (local)
The patch series introduces a new type of dma-heap, chunk heap which is
initialized by a device tree node. The chunk heap also needs its device
tree node should have a phandle to reserved memory node with "reusable"
property.
quoted
quoted
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.
quoted
Is it useful to return fewer pages than requested?
It's useful because user could ask further than what they need or retry.