On Sun, Aug 16, 2020 at 02:31:22PM +0200, David Hildenbrand wrote:
On 14.08.20 19:31, 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.
To meet the requirement, a option is using CMA area because
page allocator with compaction under memory pressure is
easily failed to meet the requirement and too slow for 4800
times. However, CMA has also the following drawbacks:
* 4800 of order-4 * cma_alloc is too slow
To avoid the slowness, we could try to allocate 300M contiguous
memory once and then split them into order-4 chunks.
The problem of this approach is CMA allocation fails one of the
pages in those range couldn't migrate out, which happens easily
with fs write under memory pressure.
Why not chose a value in between? Like try to allocate MAX_ORDER - 1
chunks and split them. That would already heavily reduce the call frequency.
I think you meant this:
alloc_pages(GFP_KERNEL|__GFP_NOWARN, MAX_ORDER - 1)
It would work if system has lots of non-fragmented free memory.
However, once they are fragmented, it doesn't work. That's why we have
seen even order-4 allocation failure in the field easily and that's why
CMA was there.
CMA has more logics to isolate the memory during allocation/freeing as
well as fragmentation avoidance so that it has less chance to be stealed
from others and increase high success ratio. That's why I want this API
to be used with CMA or movable zone.
A usecase is device can set a exclusive CMA area up when system boots.
When device needs 4800 * order-4 pages, it could call this bulk against
of the area so that it could effectively be guaranteed to allocate
enough fast.
I don't see a real need for a completely new range allocator function
for this special case yet.
quoted
To solve issues, this patch introduces alloc_pages_bulk.
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.
/**
* alloc_pages_bulk() -- tries to allocate high order pages
* by batch from given range [start, end)
* @start: start PFN to allocate
* @end: one-past-the-last PFN to allocate
* @migratetype: migratetype of the underlaying pageblocks (either
* #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks
* in range must have the same migratetype and it must
* be either of the two.
* @gfp_mask: GFP mask to use during compaction
* @order: page order requested
* @nr_elem: the number of high-order pages to allocate
* @pages: page array pointer to store allocated pages (must
* have space for at least nr_elem elements)
*
* The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
* aligned. The PFN range must belong to a single zone.
*
* Return: the number of pages allocated on success or negative error code.
* The allocated pages should be freed using __free_pages
*/
The test goes order-4 * 4800 allocation(i.e., total 300MB) under kernel
build workload. System RAM size is 1.5GB and CMA is 500M.
With using CMA to allocate to 300M, ran 10 times trial, 10 time failed
with big latency(up to several seconds).
With this alloc_pages_bulk API, ran 10 time trial, 7 times are
successful to allocate 4800 times. Rest 3 times are allocated 4799, 4789
and 4799. They are all done with 300ms.
This patchset is against on next-20200813
Minchan Kim (7):
mm: page_owner: split page by order
mm: introduce split_page_by_order
mm: compaction: deal with upcoming high-order page splitting
mm: factor __alloc_contig_range out
mm: introduce alloc_pages_bulk API
mm: make alloc_pages_bulk best effort
mm/page_isolation: avoid drain_all_pages for alloc_pages_bulk
include/linux/gfp.h | 5 +
include/linux/mm.h | 2 +
include/linux/page-isolation.h | 1 +
include/linux/page_owner.h | 10 +-
mm/compaction.c | 64 +++++++----
mm/huge_memory.c | 2 +-
mm/internal.h | 5 +-
mm/page_alloc.c | 198 ++++++++++++++++++++++++++-------
mm/page_isolation.c | 10 +-
mm/page_owner.c | 7 +-
10 files changed, 230 insertions(+), 74 deletions(-)
--
Thanks,
David / dhildenb