Chunk Heap Support on DMA-HEAP

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order

size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
bool fast, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes "bool fast parameter" which is propagated into alloc_contig_range to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough, they could call it with "false" to increase success ratio if they are okay to expense the overhead for the success ratio.

Signed-off-by Minchan Kim <[email protected]>

---
 include/linux/cma.h |   5 ++
 include/linux/gfp.h |   2 +
 mm/cma.c            | 126 ++++++++++++++++++++++++++++++++++++++++++--
 mm/page_alloc.c     |  19 ++++---
 4 files changed, 140 insertions(+), 12 deletions(-)

include/linux/cma.h +5 -0

index 217999c8a762..7375d3131804 100644
@@ -46,6 +46,11 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 					struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 			      bool no_warn);
+
+extern int cma_alloc_bulk(struct cma *cma, unsigned int align, bool fast,
+			unsigned int order, size_t nr_requests,
+			struct page **page_array, size_t *nr_allocated);
+
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
 
 extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data);

include/linux/gfp.h +2 -0

index ad5872699692..75bfb673d75b 100644
@@ -627,6 +627,8 @@ static inline bool pm_suspended_storage(void)
 enum alloc_contig_mode {
 	/* try several ways to increase success ratio of memory allocation */
 	ALLOC_CONTIG_NORMAL,
+	/* avoid costly functions to make the call fast */
+	ALLOC_CONTIG_FAST,
 };
 
 /* The below functions must be run on a range from a single zone. */

mm/cma.c +121 -5

index 8010c1ba04b0..4459045fa717 100644
@@ -32,6 +32,7 @@
 #include <linux/highmem.h>
 #include <linux/io.h>
 #include <linux/kmemleak.h>
+#include <linux/swap.h>
 #include <trace/events/cma.h>
 
 #include "cma.h"

@@ -397,6 +398,14 @@ static void cma_debug_show_areas(struct cma *cma)
 static inline void cma_debug_show_areas(struct cma *cma) { }
 #endif
 
+static void reset_page_kasan_tag(struct page *page, int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++)
+		page_kasan_tag_reset(page + i);
+}
+
 /**
  * cma_alloc() - allocate pages from contiguous area
  * @cma:   Contiguous memory region for which the allocation is performed.

@@ -414,7 +423,6 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 	unsigned long pfn = -1;
 	unsigned long start = 0;
 	unsigned long bitmap_maxno, bitmap_no, bitmap_count;
-	size_t i;
 	struct page *page = NULL;
 	int ret = -ENOMEM;
 

@@ -479,10 +487,8 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 	 * blocks being marked with different tags. Reset the tags to ignore
 	 * those page blocks.
 	 */
-	if (page) {
-		for (i = 0; i < count; i++)
-			page_kasan_tag_reset(page + i);
-	}
+	if (page)
+		reset_page_kasan_tag(page, count);
 
 	if (ret && !no_warn) {
 		pr_err("%s: alloc failed, req-size: %zu pages, ret: %d\n",

@@ -494,6 +500,116 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 	return page;
 }
 
+/*
+ * cma_alloc_bulk() - allocate high order bulk pages from contiguous area with
+ * 		best effort. It will usually be used for private @cma
+ *
+ * @cma:	contiguous memory region for which the allocation is performed.
+ * @align:	requested alignment of pages (in PAGE_SIZE order).
+ * @fast:	will skip costly opeartions if it's true.
+ * @order:	requested page order
+ * @nr_requests: the number of 2^order pages requested to be allocated as input,
+ * @page_array:	page_array pointer to store allocated pages (must have space
+ *		for at least nr_requests)
+ * @nr_allocated: the number of 2^order pages allocated as output
+ *
+ * This function tries to allocate up to @nr_requests @order pages on specific
+ * contiguous memory area. If @fast has true, it will avoid costly functions
+ * to increase allocation success ratio so it will be faster but might return
+ * less than requested number of pages. User could retry it with true if it is
+ * needed.
+ *
+ * Return: it will return 0 only if all pages requested by @nr_requestsed are
+ * allocated. Otherwise, it returns negative error code.
+ *
+ * Note: Regardless of success/failure, user should check @nr_allocated to see
+ * how many @order pages are allocated and free those pages when they are not
+ * needed.
+ */
+int cma_alloc_bulk(struct cma *cma, unsigned int align, bool fast,
+			unsigned int order, size_t nr_requests,
+			struct page **page_array, size_t *nr_allocated)
+{
+	int ret = 0;
+	size_t i = 0;
+	unsigned long nr_pages_needed = nr_requests * (1 << order);
+	unsigned long nr_chunk_pages, nr_pages;
+	unsigned long mask, offset;
+	unsigned long pfn = -1;
+	unsigned long start = 0;
+	unsigned long bitmap_maxno, bitmap_no, bitmap_count;
+	struct page *page = NULL;
+	enum alloc_contig_mode mode = fast ? ALLOC_CONTIG_FAST :
+						ALLOC_CONTIG_NORMAL;
+	*nr_allocated = 0;
+	if (!cma || !cma->count || !cma->bitmap || !page_array)
+		return -EINVAL;
+
+	if (!nr_pages_needed)
+		return 0;
+
+	nr_chunk_pages = 1 << max_t(unsigned int, order, pageblock_order);
+
+	mask = cma_bitmap_aligned_mask(cma, align);
+	offset = cma_bitmap_aligned_offset(cma, align);
+	bitmap_maxno = cma_bitmap_maxno(cma);
+
+	lru_add_drain_all();
+	drain_all_pages(NULL);
+
+	while (nr_pages_needed) {
+		nr_pages = min(nr_chunk_pages, nr_pages_needed);
+
+		bitmap_count = cma_bitmap_pages_to_bits(cma, nr_pages);
+		mutex_lock(&cma->lock);
+		bitmap_no = bitmap_find_next_zero_area_off(cma->bitmap,
+				bitmap_maxno, start, bitmap_count, mask,
+				offset);
+		if (bitmap_no >= bitmap_maxno) {
+			mutex_unlock(&cma->lock);
+			break;
+		}
+		bitmap_set(cma->bitmap, bitmap_no, bitmap_count);
+		/*
+		 * It's safe to drop the lock here. If the migration fails
+		 * cma_clear_bitmap will take the lock again and unmark it.
+		 */
+		mutex_unlock(&cma->lock);
+
+		pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
+		ret = alloc_contig_range(pfn, pfn + nr_pages, MIGRATE_CMA,
+						GFP_KERNEL|__GFP_NOWARN, mode);
+		if (ret) {
+			cma_clear_bitmap(cma, pfn, nr_pages);
+			if (ret != -EBUSY)
+				break;
+
+			/* continue to search next block */
+			start = (pfn + nr_pages - cma->base_pfn) >>
+						cma->order_per_bit;
+			continue;
+		}
+
+		page = pfn_to_page(pfn);
+		while (nr_pages) {
+			page_array[i++] = page;
+			reset_page_kasan_tag(page, 1 << order);
+			page += 1 << order;
+			nr_pages -= 1 << order;
+			nr_pages_needed -= 1 << order;
+		}
+
+		start = bitmap_no + bitmap_count;
+	}
+
+	*nr_allocated = i;
+
+	if (!ret && nr_pages_needed)
+		ret = -EBUSY;
+
+	return ret;
+}
+
 /**
  * cma_release() - release allocated pages
  * @cma:   Contiguous memory region for which the allocation is performed.

mm/page_alloc.c +12 -7

index adfbfd95fbc3..2a1799ff14fc 100644
@@ -8463,7 +8463,8 @@ static unsigned long pfn_max_align_up(unsigned long pfn)
 
 /* [start, end) must belong to a single zone. */
 static int __alloc_contig_migrate_range(struct compact_control *cc,
-					unsigned long start, unsigned long end)
+					unsigned long start, unsigned long end,
+					unsigned int max_tries)
 {
 	/* This function is based on compact_zone() from compaction.c. */
 	unsigned int nr_reclaimed;

@@ -8491,7 +8492,7 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
 				break;
 			}
 			tries = 0;
-		} else if (++tries == 5) {
+		} else if (++tries == max_tries) {
 			ret = ret < 0 ? ret : -EBUSY;
 			break;
 		}

@@ -8553,6 +8554,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	unsigned long outer_start, outer_end;
 	unsigned int order;
 	int ret = 0;
+	bool fast_mode = mode == ALLOC_CONTIG_FAST;
 
 	struct compact_control cc = {
 		.nr_migratepages = 0,

@@ -8595,7 +8597,8 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	if (ret)
 		return ret;
 
-	drain_all_pages(cc.zone);
+	if (!fast_mode)
+		drain_all_pages(cc.zone);
 
 	/*
 	 * In case of -EBUSY, we'd like to know which page causes problem.

@@ -8607,7 +8610,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	 * allocated.  So, if we fall through be sure to clear ret so that
 	 * -EBUSY is not accidentally used or returned to caller.
 	 */
-	ret = __alloc_contig_migrate_range(&cc, start, end);
+	ret = __alloc_contig_migrate_range(&cc, start, end, fast_mode ? 1 : 5);
 	if (ret && ret != -EBUSY)
 		goto done;
 	ret =0;

@@ -8629,7 +8632,8 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	 * isolated thus they won't get removed from buddy.
 	 */
 
-	lru_add_drain_all();
+	if (!fast_mode)
+		lru_add_drain_all();
 
 	order = 0;
 	outer_start = start;

@@ -8656,8 +8660,9 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 
 	/* Make sure the range is really isolated. */
 	if (test_pages_isolated(outer_start, end, 0)) {
-		pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
-			__func__, outer_start, end);
+		if (!fast_mode)
+			pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
+				__func__, outer_start, end);
 		ret = -EBUSY;
 		goto done;
 	}

Quoted 8 lines · Minchan Kim

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order

My latest knowledge is that pages in the CMA area are never long term pinned.

https://lore.kernel.org/lkml/[email protected]/

"gup already tries to deal with long term pins on CMA regions and migrate to a non CMA region. Have a look at __gup_longterm_locked."

We should rather identify ways how that is still possible and get rid of them.

Now, short-term pinnings and PCP are other issues where alloc_contig_range() could be improved (e.g., in contrast to a FAST mode, a HARD mode which temporarily disables the PCP, ...).

Quoted 18 lines

size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
bool fast, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

Quoted 9 lines

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes "bool fast parameter" which is propagated into alloc_contig_range to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough, they could call it with "false" to increase success ratio if they are okay to expense the overhead for the success ratio.

Just so I understand what the idea is:

alloc_contig_range() sometimes fails on CMA regions when trying to allocate big chunks (e.g., 300M). Instead of tackling that issue, you rather allocate plenty of small chunks, and make these small allocations fail faster/ make the allocations less reliable. Correct?

I don't really have a strong opinion on that. Giving up fast rather than trying for longer sounds like a useful thing to have - but I wonder if it's strictly necessary for the use case you describe.

I'd like to hear Michals opinion on that.

Quoted 8 lines

Signed-off-by Minchan Kim <[email protected]>

---
 include/linux/cma.h |   5 ++
 include/linux/gfp.h |   2 +
 mm/cma.c            | 126 ++++++++++++++++++++++++++++++++++++++++++--
 mm/page_alloc.c     |  19 ++++---
 4 files changed, 140 insertions(+), 12 deletions(-)

Quoted 18 lines · David Hildenbrand

Quoted 8 lines · Minchan Kim

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order

My latest knowledge is that pages in the CMA area are never long term pinned.

https://lore.kernel.org/lkml/[email protected]/

"gup already tries to deal with long term pins on CMA regions and migrate to a non CMA region. Have a look at __gup_longterm_locked."

Quoted 7 lines

We should rather identify ways how that is still possible and get rid of them.

Now, short-term pinnings and PCP are other issues where alloc_contig_range() could be improved (e.g., in contrast to a FAST mode, a HARD mode which temporarily disables the PCP, ...).

Agreed!

Quoted 39 lines

Quoted 18 lines

size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
bool fast, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

Quoted 9 lines

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes "bool fast parameter" which is propagated into alloc_contig_range to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough, they could call it with "false" to increase success ratio if they are okay to expense the overhead for the success ratio.

Just so I understand what the idea is:

alloc_contig_range() sometimes fails on CMA regions when trying to allocate big chunks (e.g., 300M). Instead of tackling that issue, you rather allocate plenty of small chunks, and make these small allocations fail faster/ make the allocations less reliable. Correct?

I don't really have a strong opinion on that. Giving up fast rather than trying for longer sounds like a useful thing to have - but I wonder if it's strictly necessary for the use case you describe.

Quoted 1 line

I'd like to hear Michals opinion on that.

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

Quoted 18 lines · David Hildenbrand

Quoted 8 lines · Minchan Kim

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order

My latest knowledge is that pages in the CMA area are never long term pinned.

https://lore.kernel.org/lkml/[email protected]/

"gup already tries to deal with long term pins on CMA regions and migrate to a non CMA region. Have a look at __gup_longterm_locked."

Quoted 7 lines

We should rather identify ways how that is still possible and get rid of them.

Now, short-term pinnings and PCP are other issues where alloc_contig_range() could be improved (e.g., in contrast to a FAST mode, a HARD mode which temporarily disables the PCP, ...).

Agreed!

Quoted 39 lines

Quoted 18 lines

size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
bool fast, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

Quoted 9 lines

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes "bool fast parameter" which is propagated into alloc_contig_range to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough, they could call it with "false" to increase success ratio if they are okay to expense the overhead for the success ratio.

Just so I understand what the idea is:

alloc_contig_range() sometimes fails on CMA regions when trying to allocate big chunks (e.g., 300M). Instead of tackling that issue, you rather allocate plenty of small chunks, and make these small allocations fail faster/ make the allocations less reliable. Correct?

I don't really have a strong opinion on that. Giving up fast rather than trying for longer sounds like a useful thing to have - but I wonder if it's strictly necessary for the use case you describe.

Quoted 1 line

I'd like to hear Michals opinion on that.

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Quoted 9 lines

Quoted 9 lines

Signed-off-by Minchan Kim <[email protected]>

---
 include/linux/cma.h |   5 ++
 include/linux/gfp.h |   2 +
 mm/cma.c            | 126 ++++++++++++++++++++++++++++++++++++++++++--
 mm/page_alloc.c     |  19 ++++---
 4 files changed, 140 insertions(+), 12 deletions(-)

Signature · 2 lines

Michal Hocko
SUSE Labs

On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:

Quoted 6 lines

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

If we use cma_alloc, that interface requires "allocate one big memory chunk". IOW, return value is just struct page and expected that the page is a big contiguos memory. That means it couldn't have a hole in the range.
However the idea here, what we asked is much smaller chunk rather than a big contiguous memory so we could skip some of pages if they are randomly pinned(long-term/short-term whatever) and search other pages in the CMA area to avoid long stall. Thus, it couldn't work with exising cma_alloc API with simple gfp_mak.

Quoted 5 lines

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Yub, true with other overheads(e.g., migration retrial, waiting writeback PCP/LRU draining IPI)

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:

[...]

Quoted 7 lines

Quoted 6 lines

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

Quoted 9 lines

If we use cma_alloc, that interface requires "allocate one big memory chunk". IOW, return value is just struct page and expected that the page is a big contiguos memory. That means it couldn't have a hole in the range.
However the idea here, what we asked is much smaller chunk rather than a big contiguous memory so we could skip some of pages if they are randomly pinned(long-term/short-term whatever) and search other pages in the CMA area to avoid long stall. Thus, it couldn't work with exising cma_alloc API with simple gfp_mak.

I really do not see that as something really alient to the cma_alloc interface. All you should care about, really, is what size of the object you want and how hard the system should try. If you have a problem with an internal implementation of CMA and how it chooses a range and deal with pinned pages then it should be addressed inside the CMA allocator. I suspect that you are effectivelly trying to workaround those problems by a side implementation with a slightly different API. Or maybe I still do not follow the actual problem.

Quoted 6 lines

Quoted 5 lines

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Quoted 2 lines

Yub, true with other overheads(e.g., migration retrial, waiting writeback PCP/LRU draining IPI)

Why cannot this be implemented in the cma_alloc layer? I mean you can cache failed cases and optimize the proper pfn range search.

Quoted 35 lines · Michal Hocko

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:

[...]

Quoted 7 lines

Quoted 6 lines

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

Quoted 9 lines

If we use cma_alloc, that interface requires "allocate one big memory chunk". IOW, return value is just struct page and expected that the page is a big contiguos memory. That means it couldn't have a hole in the range.
However the idea here, what we asked is much smaller chunk rather than a big contiguous memory so we could skip some of pages if they are randomly pinned(long-term/short-term whatever) and search other pages in the CMA area to avoid long stall. Thus, it couldn't work with exising cma_alloc API with simple gfp_mak.

I really do not see that as something really alient to the cma_alloc interface. All you should care about, really, is what size of the object you want and how hard the system should try. If you have a problem with an internal implementation of CMA and how it chooses a range and deal with pinned pages then it should be addressed inside the CMA allocator. I suspect that you are effectivelly trying to workaround those problems by a side implementation with a slightly different API. Or maybe I still do not follow the actual problem.

Quoted 6 lines

Quoted 5 lines

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Quoted 5 lines

Quoted 2 lines

Yub, true with other overheads(e.g., migration retrial, waiting writeback PCP/LRU draining IPI)

Why cannot this be implemented in the cma_alloc layer? I mean you can cache failed cases and optimize the proper pfn range search.

So do you suggest this?

enum cma_alloc_mode {
CMA_ALLOC_NORMAL,
CMA_ALLOC_FAIL_FAST,
};

struct page *cma_alloc(struct cma *cma, size_t count, unsigned int

	align, enum cma_alloc_mode mode);

Quoted 1 line

From now on, cma_alloc will keep last failed pfn and then start to

search from the next pfn for both CMA_ALLOC_NORMAL and CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay within CMA area and then wraparound it couldn't find right pages from the cached pfn. Othewise, the cached pfn will reset to the zero so that it starts the search from the 0. I like the idea since it's general improvement, I think.

Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads at the cost of sacrificing allocation success ratio like GFP_NORETRY.

I think that would solve the issue with making the API more flexible. Before diving into it, I'd like to confirm we are on same page. Please correct me if I misunderstood.

Quoted 52 lines · Minchan Kim

Quoted 35 lines · Michal Hocko

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:

[...]

Quoted 7 lines

Quoted 6 lines

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

Quoted 9 lines

If we use cma_alloc, that interface requires "allocate one big memory chunk". IOW, return value is just struct page and expected that the page is a big contiguos memory. That means it couldn't have a hole in the range.
However the idea here, what we asked is much smaller chunk rather than a big contiguous memory so we could skip some of pages if they are randomly pinned(long-term/short-term whatever) and search other pages in the CMA area to avoid long stall. Thus, it couldn't work with exising cma_alloc API with simple gfp_mak.

I really do not see that as something really alient to the cma_alloc interface. All you should care about, really, is what size of the object you want and how hard the system should try. If you have a problem with an internal implementation of CMA and how it chooses a range and deal with pinned pages then it should be addressed inside the CMA allocator. I suspect that you are effectivelly trying to workaround those problems by a side implementation with a slightly different API. Or maybe I still do not follow the actual problem.

Quoted 6 lines

Quoted 5 lines

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Quoted 5 lines

Quoted 2 lines

Yub, true with other overheads(e.g., migration retrial, waiting writeback PCP/LRU draining IPI)

Why cannot this be implemented in the cma_alloc layer? I mean you can cache failed cases and optimize the proper pfn range search.

So do you suggest this?

enum cma_alloc_mode {
CMA_ALLOC_NORMAL,
CMA_ALLOC_FAIL_FAST,
};

struct page *cma_alloc(struct cma *cma, size_t count, unsigned int

	align, enum cma_alloc_mode mode);

Quoted 7 lines

Quoted 1 line

From now on, cma_alloc will keep last failed pfn and then start to

search from the next pfn for both CMA_ALLOC_NORMAL and CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay within CMA area and then wraparound it couldn't find right pages from the cached pfn. Othewise, the cached pfn will reset to the zero so that it starts the search from the 0. I like the idea since it's general improvement, I think.

Yes something like that. There are more options to be clever here - e.g. track ranges etc. but I am not sure this is worth the complexity.

Quoted 3 lines

Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads at the cost of sacrificing allocation success ratio like GFP_NORETRY.

I am still not sure a specific flag is a good interface. Really can this be gfp_mask instead?

Quoted 4 lines

I think that would solve the issue with making the API more flexible. Before diving into it, I'd like to confirm we are on same page. Please correct me if I misunderstood.

I am not sure you are still thinking about a bulk interface.

Quoted 61 lines · Michal Hocko

Quoted 52 lines · Minchan Kim

Quoted 35 lines · Michal Hocko

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:

[...]

Quoted 7 lines

Quoted 6 lines

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

Quoted 9 lines

If we use cma_alloc, that interface requires "allocate one big memory chunk". IOW, return value is just struct page and expected that the page is a big contiguos memory. That means it couldn't have a hole in the range.
However the idea here, what we asked is much smaller chunk rather than a big contiguous memory so we could skip some of pages if they are randomly pinned(long-term/short-term whatever) and search other pages in the CMA area to avoid long stall. Thus, it couldn't work with exising cma_alloc API with simple gfp_mak.

I really do not see that as something really alient to the cma_alloc interface. All you should care about, really, is what size of the object you want and how hard the system should try. If you have a problem with an internal implementation of CMA and how it chooses a range and deal with pinned pages then it should be addressed inside the CMA allocator. I suspect that you are effectivelly trying to workaround those problems by a side implementation with a slightly different API. Or maybe I still do not follow the actual problem.

Quoted 6 lines

Quoted 5 lines

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Quoted 5 lines

Quoted 2 lines

Yub, true with other overheads(e.g., migration retrial, waiting writeback PCP/LRU draining IPI)

Why cannot this be implemented in the cma_alloc layer? I mean you can cache failed cases and optimize the proper pfn range search.

So do you suggest this?

enum cma_alloc_mode {
CMA_ALLOC_NORMAL,
CMA_ALLOC_FAIL_FAST,
};

struct page *cma_alloc(struct cma *cma, size_t count, unsigned int

	align, enum cma_alloc_mode mode);

Quoted 7 lines

Quoted 1 line

From now on, cma_alloc will keep last failed pfn and then start to

search from the next pfn for both CMA_ALLOC_NORMAL and CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay within CMA area and then wraparound it couldn't find right pages from the cached pfn. Othewise, the cached pfn will reset to the zero so that it starts the search from the 0. I like the idea since it's general improvement, I think.

Quoted 2 lines

Yes something like that. There are more options to be clever here - e.g. track ranges etc. but I am not sure this is worth the complexity.

Agree. Just last pfn caching would be good enough as simple start.

Quoted 4 lines

Quoted 3 lines

Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads at the cost of sacrificing allocation success ratio like GFP_NORETRY.

Quoted 2 lines

I am still not sure a specific flag is a good interface. Really can this be gfp_mask instead?

I am not strong(even, I did it with GFP_NORETRY) but David wanted to have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as one of options in future(it would be hard to indicate that mode with gfp flags).

Quoted 71 lines · Minchan Kim

Quoted 61 lines · Michal Hocko

Quoted 52 lines · Minchan Kim

Quoted 35 lines · Michal Hocko

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote:

[...]

Quoted 7 lines

Quoted 6 lines

Well, what I can see is that this new interface is an antipatern to our allocation routines. We tend to control allocations by gfp mask yet you are introducing a bool parameter to make something faster... What that really means is rather arbitrary. Would it make more sense to teach cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. GFP_RETRY_MAYFAIL instead?

Quoted 9 lines

If we use cma_alloc, that interface requires "allocate one big memory chunk". IOW, return value is just struct page and expected that the page is a big contiguos memory. That means it couldn't have a hole in the range.
However the idea here, what we asked is much smaller chunk rather than a big contiguous memory so we could skip some of pages if they are randomly pinned(long-term/short-term whatever) and search other pages in the CMA area to avoid long stall. Thus, it couldn't work with exising cma_alloc API with simple gfp_mak.

I really do not see that as something really alient to the cma_alloc interface. All you should care about, really, is what size of the object you want and how hard the system should try. If you have a problem with an internal implementation of CMA and how it chooses a range and deal with pinned pages then it should be addressed inside the CMA allocator. I suspect that you are effectivelly trying to workaround those problems by a side implementation with a slightly different API. Or maybe I still do not follow the actual problem.

Quoted 6 lines

Quoted 5 lines

I am not deeply familiar with the cma allocator so sorry for a potentially stupid question. Why does a bulk interface performs better than repeated calls to cma_alloc? Is this because a failure would help to move on to the next pfn range while a repeated call would have to deal with the same range?

Quoted 5 lines

Quoted 2 lines

Yub, true with other overheads(e.g., migration retrial, waiting writeback PCP/LRU draining IPI)

Why cannot this be implemented in the cma_alloc layer? I mean you can cache failed cases and optimize the proper pfn range search.

So do you suggest this?

enum cma_alloc_mode {
CMA_ALLOC_NORMAL,
CMA_ALLOC_FAIL_FAST,
};

struct page *cma_alloc(struct cma *cma, size_t count, unsigned int

	align, enum cma_alloc_mode mode);

Quoted 7 lines

Quoted 1 line

From now on, cma_alloc will keep last failed pfn and then start to

search from the next pfn for both CMA_ALLOC_NORMAL and CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay within CMA area and then wraparound it couldn't find right pages from the cached pfn. Othewise, the cached pfn will reset to the zero so that it starts the search from the 0. I like the idea since it's general improvement, I think.

Quoted 2 lines

Yes something like that. There are more options to be clever here - e.g. track ranges etc. but I am not sure this is worth the complexity.

Agree. Just last pfn caching would be good enough as simple start.

Quoted 4 lines

Quoted 3 lines

Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads at the cost of sacrificing allocation success ratio like GFP_NORETRY.

Quoted 7 lines

Quoted 2 lines

I am still not sure a specific flag is a good interface. Really can this be gfp_mask instead?

I am not strong(even, I did it with GFP_NORETRY) but David wanted to have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as one of options in future(it would be hard to indicate that mode with gfp flags).

I can't tell regarding the CMA interface, but for the alloc_contig() interface I think modes make sense. Yes, it's different to other allocaters, but the contig range allocater is different already. E.g., the CMA allocater mostly hides "which exact PFNs you try to allocate".

In the contig range allocater, gfp flags are currently used to express how to allocate pages used as migration targets. I don't think mangling in other gfp flags (or even overloading them) makes things a lot clearer. E.g., GFP_NORETRY: don't retry to allocate migration targets? don't retry to migrate pages? both?

As I said, other aspects might be harder to model (e.g., don't drain LRU) and hiding them behind generic gfp flags (e.g., GFP_NORETRY) feels wrong.

With the mode, we're expressing details for the necessary page migration. Suggestions on how to model that are welcome.

Signature · 3 lines

Thanks,

David / dhildenb

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote:

Quoted 7 lines

Quoted 2 lines

I am still not sure a specific flag is a good interface. Really can this be gfp_mask instead?

I am not strong(even, I did it with GFP_NORETRY) but David wanted to have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as one of options in future(it would be hard to indicate that mode with gfp flags).

I can't tell regarding the CMA interface, but for the alloc_contig() interface I think modes make sense. Yes, it's different to other allocaters, but the contig range allocater is different already. E.g., the CMA allocater mostly hides "which exact PFNs you try to allocate".

In the contig range allocater, gfp flags are currently used to express how to allocate pages used as migration targets. I don't think mangling in other gfp flags (or even overloading them) makes things a lot clearer. E.g., GFP_NORETRY: don't retry to allocate migration targets? don't retry to migrate pages? both?

As I said, other aspects might be harder to model (e.g., don't drain LRU) and hiding them behind generic gfp flags (e.g., GFP_NORETRY) feels wrong.

With the mode, we're expressing details for the necessary page migration. Suggestions on how to model that are welcome.

Quoted 2 lines · David Hildenbrand

Quoted 1 line · Minchan Kim

On Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote:

[...]

Quoted 8 lines

Quoted 7 lines

Quoted 2 lines

I am still not sure a specific flag is a good interface. Really can this be gfp_mask instead?

I am not strong(even, I did it with GFP_NORETRY) but David wanted to have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as one of options in future(it would be hard to indicate that mode with gfp flags).

Quoted 4 lines

I can't tell regarding the CMA interface, but for the alloc_contig() interface I think modes make sense. Yes, it's different to other allocaters, but the contig range allocater is different already. E.g., the CMA allocater mostly hides "which exact PFNs you try to allocate".

Yes, alloc_contig_range is a low level API but it already has a gfp_mask parameter. Adding yet another allocation mode sounds like API convolution to me.

Quoted 11 lines

In the contig range allocater, gfp flags are currently used to express how to allocate pages used as migration targets. I don't think mangling in other gfp flags (or even overloading them) makes things a lot clearer. E.g., GFP_NORETRY: don't retry to allocate migration targets? don't retry to migrate pages? both?

As I said, other aspects might be harder to model (e.g., don't drain LRU) and hiding them behind generic gfp flags (e.g., GFP_NORETRY) feels wrong.

Quoted 2 lines

With the mode, we're expressing details for the necessary page migration. Suggestions on how to model that are welcome.

The question is whether the caller should really have such an intimate knowledge and control of the alloc_contig_range implementation. This all are implementation details. Should really anybody think about how many times migration retries or control LRU draining? Those can change in the

future and I do not think we really want to go over all users grown over that time and try to deduce what was the intention behind.

I think we should aim at easy and very highlevel behavior:
- GFP_NOWAIT - unsupported currently IIRC but something that something that should be possible to implement. Isolation is non blocking, migration could be skipped
- GFP_KERNEL - default behavior whatever that means
- GFP_NORETRY - opportunistic allocation as lightweight as we can get. Failures to be expected also for transient reasons.
- GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption (e.g. via oom killer).

- __GFP_THIS_NODE - stick to a node without fallback
- we can support zone modifiers although there is no existing user.
- __GFP_NOWARN - obvious

And that is it. Or maybe I am seeing that oversimplified.

On 03.12.20 09:28, Michal Hocko wrote:

Quoted 9 lines

I think we should aim at easy and very highlevel behavior:
- GFP_NOWAIT - unsupported currently IIRC but something that something that should be possible to implement. Isolation is non blocking, migration could be skipped
- GFP_KERNEL - default behavior whatever that means
- GFP_NORETRY - opportunistic allocation as lightweight as we can get. Failures to be expected also for transient reasons.
- GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption (e.g. via oom killer).

I think we currently see demand for 3 modes for alloc_contig_range()

a) normal

As is. Try, but don't try too hard. E.g., drain LRU, drain PCP, retry a couple of times. Failures in some cases (short-term pinning, PCP races) are still possible and acceptable.

GFP_RETRY_MAYFAIL ?

E.g., "Allocations with this flag may fail, but only when there is genuinely little unused memory." - current description does not match at all. When allocating ranges things behave completely different.

b) fast

Try, but fail fast. Leave optimizations that can improve the result to the caller. E.g., don't drain LRU, don't drain PCP, don't retry. Frequent failures are expected and acceptable.

__GFP_NORETRY ?

E.g., "The VM implementation will try only very lightweight memory direct reclaim to get some memory under memory pressure" - again, I think current description does not really match.

c) hard

Try hard, E.g., temporarily disabling the PCP. Certainly not __GFP_NOFAIL, that would be highly dangerous. So no flags / GFP_KERNEL?

Quoted 6 lines

- __GFP_THIS_NODE - stick to a node without fallback
- we can support zone modifiers although there is no existing user.
- __GFP_NOWARN - obvious

And that is it. Or maybe I am seeing that oversimplified.

Again, I think most flags make sense for the migration target allocation
path and mainly deal with OOM situations and reclaim. For the migration
path - which is specific to the alloc_contig_range() allocater - they don't really apply and create more confusion than they actually help - IMHO.

Quoted 1 line · David Hildenbrand

On 03.12.20 09:28, Michal Hocko wrote:

[...]

Quoted 12 lines

Quoted 9 lines

I think we should aim at easy and very highlevel behavior:
- GFP_NOWAIT - unsupported currently IIRC but something that something that should be possible to implement. Isolation is non blocking, migration could be skipped
- GFP_KERNEL - default behavior whatever that means
- GFP_NORETRY - opportunistic allocation as lightweight as we can get. Failures to be expected also for transient reasons.
- GFP_RETRY_MAYFAIL - try hard but not as hard as to trigger disruption (e.g. via oom killer).

I think we currently see demand for 3 modes for alloc_contig_range()

Quoted 7 lines

a) normal

As is. Try, but don't try too hard. E.g., drain LRU, drain PCP, retry a couple of times. Failures in some cases (short-term pinning, PCP races) are still possible and acceptable.

GFP_RETRY_MAYFAIL ?

normal shouldn't really require anybody to think about gfp flags hard. That to most people really means GFP_KERNEL.

Quoted 11 lines

E.g., "Allocations with this flag may fail, but only when there is genuinely little unused memory." - current description does not match at all. When allocating ranges things behave completely different.

b) fast

Try, but fail fast. Leave optimizations that can improve the result to the caller. E.g., don't drain LRU, don't drain PCP, don't retry. Frequent failures are expected and acceptable.

Quoted 5 lines

__GFP_NORETRY ?

E.g., "The VM implementation will try only very lightweight memory direct reclaim to get some memory under memory pressure" - again, I think current description does not really match.

Agreed. As mentioned above this would be an opportunistic allocation mode.

Quoted 4 lines

c) hard

Try hard, E.g., temporarily disabling the PCP. Certainly not __GFP_NOFAIL, that would be highly dangerous. So no flags / GFP_KERNEL?

NOFAIL semantic is out of question. Should we have a mode to try harder than the default? I dunno. Do we have users? I think RETRY_MAYFAIL is a middle ground between the default and NORETRY which is just too easy to fail. This is the case for the allocator as well. And from what I have seen people are already using MAYFAIL in order to prevent oom killer so this is a generally recognized pattern.

Quoted 8 lines

Quoted 7 lines

- __GFP_THIS_NODE - stick to a node without fallback
- we can support zone modifiers although there is no existing user.
- __GFP_NOWARN - obvious

And that is it. Or maybe I am seeing that oversimplified.

Quoted 4 lines

Again, I think most flags make sense for the migration target allocation
path and mainly deal with OOM situations and reclaim. For the migration
path - which is specific to the alloc_contig_range() allocater - they don't really apply and create more confusion than they actually help - IMHO.

Migration is really an implementation detail of this interface. You shouldn't be even thinking that there is a migration underneath not even mention to actually trying to control it.

Quoted 8 lines · Minchan Kim

There is a need for special HW to require bulk allocation of high-order pages. For example, 4800 * order-4 pages, which would be minimum, sometimes, it requires more.

To meet the requirement, a option reserves 300M CMA area and requests the whole 300M contiguous memory. However, it doesn't work if even one of those pages in the range is long-term pinned directly or indirectly. The other option is to ask higher-order

My latest knowledge is that pages in the CMA area are never long term pinned.

https://lore.kernel.org/lkml/[email protected]/

"gup already tries to deal with long term pins on CMA regions and migrate to a non CMA region. Have a look at __gup_longterm_locked."

We should rather identify ways how that is still possible and get rid of them.

Now, short-term pinnings and PCP are other issues where alloc_contig_range() could be improved (e.g., in contrast to a FAST mode, a HARD mode which temporarily disables the PCP, ...).

Quoted 19 lines

size (e.g., 2M) than requested order(64K) repeatedly until driver could gather necessary amount of memory. Basically, this approach makes the allocation very slow due to cma_alloc's function slowness and it could be stuck on one of the pageblocks if it encounters unmigratable page.

To solve the issue, this patch introduces cma_alloc_bulk.

int cma_alloc_bulk(struct cma *cma, unsigned int align,
bool fast, unsigned int order, size_t nr_requests, struct page **page_array, size_t *nr_allocated);

Most parameters are same with cma_alloc but it additionally passes vector array to store allocated memory. What's different with cma_alloc is it will skip pageblocks without waiting/stopping if it has unmovable page so that API continues to scan other pageblocks to find requested order page.

Quoted 9 lines

cma_alloc_bulk is best effort approach in that it skips some pageblocks if they have unmovable pages unlike cma_alloc. It doesn't need to be perfect from the beginning at the cost of performance. Thus, the API takes "bool fast parameter" which is propagated into alloc_contig_range to avoid significat overhead functions to inrecase CMA allocation success ratio(e.g., migration retrial, PCP, LRU draining per pageblock) at the cost of less allocation success ratio. If the caller couldn't allocate enough, they could call it with "false" to increase success ratio if they are okay to expense the overhead for the success ratio.

Just so I understand what the idea is:

alloc_contig_range() sometimes fails on CMA regions when trying to allocate big chunks (e.g., 300M). Instead of tackling that issue, you rather allocate plenty of small chunks, and make these small allocations fail faster/ make the allocations less reliable. Correct?

I don't really have a strong opinion on that. Giving up fast rather than trying for longer sounds like a useful thing to have - but I wonder if it's strictly necessary for the use case you describe.

I'd like to hear Michals opinion on that.

Quoted 276 lines

Signed-off-by Minchan Kim <[email protected]>

---
 include/linux/cma.h |   5 ++
 include/linux/gfp.h |   2 +
 mm/cma.c            | 126 ++++++++++++++++++++++++++++++++++++++++++--
 mm/page_alloc.c     |  19 ++++---
 4 files changed, 140 insertions(+), 12 deletions(-)

include/linux/cma.h +5 -0

index 217999c8a762..7375d3131804 100644
@@ -46,6 +46,11 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 					struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 			      bool no_warn);
+
+extern int cma_alloc_bulk(struct cma *cma, unsigned int align, bool fast,
+			unsigned int order, size_t nr_requests,
+			struct page **page_array, size_t *nr_allocated);
+
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
 
 extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data);

include/linux/gfp.h +2 -0

index ad5872699692..75bfb673d75b 100644
@@ -627,6 +627,8 @@ static inline bool pm_suspended_storage(void)
 enum alloc_contig_mode {
 	/* try several ways to increase success ratio of memory allocation */
 	ALLOC_CONTIG_NORMAL,
+	/* avoid costly functions to make the call fast */
+	ALLOC_CONTIG_FAST,
 };
 
 /* The below functions must be run on a range from a single zone. */

mm/cma.c +121 -5

index 8010c1ba04b0..4459045fa717 100644
@@ -32,6 +32,7 @@
 #include <linux/highmem.h>
 #include <linux/io.h>
 #include <linux/kmemleak.h>
+#include <linux/swap.h>
 #include <trace/events/cma.h>
 
 #include "cma.h"

@@ -397,6 +398,14 @@ static void cma_debug_show_areas(struct cma *cma)
 static inline void cma_debug_show_areas(struct cma *cma) { }
 #endif
 
+static void reset_page_kasan_tag(struct page *page, int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++)
+		page_kasan_tag_reset(page + i);
+}
+
 /**
  * cma_alloc() - allocate pages from contiguous area
  * @cma:   Contiguous memory region for which the allocation is performed.

@@ -414,7 +423,6 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 	unsigned long pfn = -1;
 	unsigned long start = 0;
 	unsigned long bitmap_maxno, bitmap_no, bitmap_count;
-	size_t i;
 	struct page *page = NULL;
 	int ret = -ENOMEM;
 

@@ -479,10 +487,8 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 	 * blocks being marked with different tags. Reset the tags to ignore
 	 * those page blocks.
 	 */
-	if (page) {
-		for (i = 0; i < count; i++)
-			page_kasan_tag_reset(page + i);
-	}
+	if (page)
+		reset_page_kasan_tag(page, count);
 
 	if (ret && !no_warn) {
 		pr_err("%s: alloc failed, req-size: %zu pages, ret: %d\n",

@@ -494,6 +500,116 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align,
 	return page;
 }
 
+/*
+ * cma_alloc_bulk() - allocate high order bulk pages from contiguous area with
+ * 		best effort. It will usually be used for private @cma
+ *
+ * @cma:	contiguous memory region for which the allocation is performed.
+ * @align:	requested alignment of pages (in PAGE_SIZE order).
+ * @fast:	will skip costly opeartions if it's true.
+ * @order:	requested page order
+ * @nr_requests: the number of 2^order pages requested to be allocated as input,
+ * @page_array:	page_array pointer to store allocated pages (must have space
+ *		for at least nr_requests)
+ * @nr_allocated: the number of 2^order pages allocated as output
+ *
+ * This function tries to allocate up to @nr_requests @order pages on specific
+ * contiguous memory area. If @fast has true, it will avoid costly functions
+ * to increase allocation success ratio so it will be faster but might return
+ * less than requested number of pages. User could retry it with true if it is
+ * needed.
+ *
+ * Return: it will return 0 only if all pages requested by @nr_requestsed are
+ * allocated. Otherwise, it returns negative error code.
+ *
+ * Note: Regardless of success/failure, user should check @nr_allocated to see
+ * how many @order pages are allocated and free those pages when they are not
+ * needed.
+ */
+int cma_alloc_bulk(struct cma *cma, unsigned int align, bool fast,
+			unsigned int order, size_t nr_requests,
+			struct page **page_array, size_t *nr_allocated)
+{
+	int ret = 0;
+	size_t i = 0;
+	unsigned long nr_pages_needed = nr_requests * (1 << order);
+	unsigned long nr_chunk_pages, nr_pages;
+	unsigned long mask, offset;
+	unsigned long pfn = -1;
+	unsigned long start = 0;
+	unsigned long bitmap_maxno, bitmap_no, bitmap_count;
+	struct page *page = NULL;
+	enum alloc_contig_mode mode = fast ? ALLOC_CONTIG_FAST :
+						ALLOC_CONTIG_NORMAL;
+	*nr_allocated = 0;
+	if (!cma || !cma->count || !cma->bitmap || !page_array)
+		return -EINVAL;
+
+	if (!nr_pages_needed)
+		return 0;
+
+	nr_chunk_pages = 1 << max_t(unsigned int, order, pageblock_order);
+
+	mask = cma_bitmap_aligned_mask(cma, align);
+	offset = cma_bitmap_aligned_offset(cma, align);
+	bitmap_maxno = cma_bitmap_maxno(cma);
+
+	lru_add_drain_all();
+	drain_all_pages(NULL);
+
+	while (nr_pages_needed) {
+		nr_pages = min(nr_chunk_pages, nr_pages_needed);
+
+		bitmap_count = cma_bitmap_pages_to_bits(cma, nr_pages);
+		mutex_lock(&cma->lock);
+		bitmap_no = bitmap_find_next_zero_area_off(cma->bitmap,
+				bitmap_maxno, start, bitmap_count, mask,
+				offset);
+		if (bitmap_no >= bitmap_maxno) {
+			mutex_unlock(&cma->lock);
+			break;
+		}
+		bitmap_set(cma->bitmap, bitmap_no, bitmap_count);
+		/*
+		 * It's safe to drop the lock here. If the migration fails
+		 * cma_clear_bitmap will take the lock again and unmark it.
+		 */
+		mutex_unlock(&cma->lock);
+
+		pfn = cma->base_pfn + (bitmap_no << cma->order_per_bit);
+		ret = alloc_contig_range(pfn, pfn + nr_pages, MIGRATE_CMA,
+						GFP_KERNEL|__GFP_NOWARN, mode);
+		if (ret) {
+			cma_clear_bitmap(cma, pfn, nr_pages);
+			if (ret != -EBUSY)
+				break;
+
+			/* continue to search next block */
+			start = (pfn + nr_pages - cma->base_pfn) >>
+						cma->order_per_bit;
+			continue;
+		}
+
+		page = pfn_to_page(pfn);
+		while (nr_pages) {
+			page_array[i++] = page;
+			reset_page_kasan_tag(page, 1 << order);
+			page += 1 << order;
+			nr_pages -= 1 << order;
+			nr_pages_needed -= 1 << order;
+		}
+
+		start = bitmap_no + bitmap_count;
+	}
+
+	*nr_allocated = i;
+
+	if (!ret && nr_pages_needed)
+		ret = -EBUSY;
+
+	return ret;
+}
+
 /**
  * cma_release() - release allocated pages
  * @cma:   Contiguous memory region for which the allocation is performed.

mm/page_alloc.c +12 -7

index adfbfd95fbc3..2a1799ff14fc 100644
@@ -8463,7 +8463,8 @@ static unsigned long pfn_max_align_up(unsigned long pfn)
 
 /* [start, end) must belong to a single zone. */
 static int __alloc_contig_migrate_range(struct compact_control *cc,
-					unsigned long start, unsigned long end)
+					unsigned long start, unsigned long end,
+					unsigned int max_tries)
 {
 	/* This function is based on compact_zone() from compaction.c. */
 	unsigned int nr_reclaimed;

@@ -8491,7 +8492,7 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
 				break;
 			}
 			tries = 0;
-		} else if (++tries == 5) {
+		} else if (++tries == max_tries) {
 			ret = ret < 0 ? ret : -EBUSY;
 			break;
 		}

@@ -8553,6 +8554,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	unsigned long outer_start, outer_end;
 	unsigned int order;
 	int ret = 0;
+	bool fast_mode = mode == ALLOC_CONTIG_FAST;
 
 	struct compact_control cc = {
 		.nr_migratepages = 0,

@@ -8595,7 +8597,8 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	if (ret)
 		return ret;
 
-	drain_all_pages(cc.zone);
+	if (!fast_mode)
+		drain_all_pages(cc.zone);
 
 	/*
 	 * In case of -EBUSY, we'd like to know which page causes problem.

@@ -8607,7 +8610,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	 * allocated.  So, if we fall through be sure to clear ret so that
 	 * -EBUSY is not accidentally used or returned to caller.
 	 */
-	ret = __alloc_contig_migrate_range(&cc, start, end);
+	ret = __alloc_contig_migrate_range(&cc, start, end, fast_mode ? 1 : 5);
 	if (ret && ret != -EBUSY)
 		goto done;
 	ret =0;

@@ -8629,7 +8632,8 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 	 * isolated thus they won't get removed from buddy.
 	 */
 
-	lru_add_drain_all();
+	if (!fast_mode)
+		lru_add_drain_all();
 
 	order = 0;
 	outer_start = start;

@@ -8656,8 +8660,9 @@ int alloc_contig_range(unsigned long start, unsigned long end,
 
 	/* Make sure the range is really isolated. */
 	if (test_pages_isolated(outer_start, end, 0)) {
-		pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
-			__func__, outer_start, end);
+		if (!fast_mode)
+			pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
+				__func__, outer_start, end);
 		ret = -EBUSY;
 		goto done;
 	}

Signature · 3 lines

Thanks,

David / dhildenb

From: Hyesoo Yu <[email protected]>

The heaps could be added as module, so some functions should be exported to register dma-heaps. And dma-heap of module can use cma area to allocate and free. However the function related cma is not exported now. Let's export them for next patches.

Signed-off-by Hyesoo Yu <[email protected]>

Signed-off-by Minchan Kim <[email protected]>

drivers/dma-buf/heaps/chunk_heap.c new file +7 -0

+static int __init chunk_heap_init(void)
+{
+       struct cma *default_cma = dev_get_cma_area(NULL);
+       struct dma_heap_export_info exp_info;
+       struct chunk_heap *chunk_heap;
+
+       if (!default_cma)

On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim <[email protected]> wrote:

Thanks for reworking and resending this!

...

Quoted 7 lines

drivers/dma-buf/heaps/chunk_heap.c new file +7 -0

+static int __init chunk_heap_init(void)
+{
+       struct cma *default_cma = dev_get_cma_area(NULL);
+       struct dma_heap_export_info exp_info;
+       struct chunk_heap *chunk_heap;
+
+       if (!default_cma)

drivers/dma-buf/heaps/chunk_heap.c line 413

Quoted 10 lines

drivers/dma-buf/heaps/chunk_heap.c new file +10 -0

+               return 0;
+
+       chunk_heap = kzalloc(sizeof(*chunk_heap), GFP_KERNEL);
+       if (!chunk_heap)
+               return -ENOMEM;
+
+       chunk_heap->order = CHUNK_HEAP_ORDER;
+       chunk_heap->cma = default_cma;
+
+       exp_info.name = cma_get_name(default_cma);

So, this would create a chunk heap name with the default CMA name, which would be indistinguishable from the heap name used for the plain CMA heap.

Probably a good idea to prefix it with "chunk-" so the heap device names are unique?

Quoted 27 lines · John Stultz

On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim <[email protected]> wrote:

Thanks for reworking and resending this!

...

Quoted 7 lines

drivers/dma-buf/heaps/chunk_heap.c new file +7 -0

+static int __init chunk_heap_init(void)
+{
+       struct cma *default_cma = dev_get_cma_area(NULL);
+       struct dma_heap_export_info exp_info;
+       struct chunk_heap *chunk_heap;
+
+       if (!default_cma)

drivers/dma-buf/heaps/chunk_heap.c line 413

Quoted 10 lines

drivers/dma-buf/heaps/chunk_heap.c new file +10 -0

+               return 0;
+
+       chunk_heap = kzalloc(sizeof(*chunk_heap), GFP_KERNEL);
+       if (!chunk_heap)
+               return -ENOMEM;
+
+       chunk_heap->order = CHUNK_HEAP_ORDER;
+       chunk_heap->cma = default_cma;
+
+       exp_info.name = cma_get_name(default_cma);

So, this would create a chunk heap name with the default CMA name, which would be indistinguishable from the heap name used for the plain CMA heap.

Quoted 2 lines

Probably a good idea to prefix it with "chunk-" so the heap device names are unique?

That will give an impression to user that they are using different CMA area but that's not true. IMHO, let's be honest at this moment.

Quoted 28 lines · Minchan Kim

Quoted 27 lines · John Stultz

On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim <[email protected]> wrote:

Thanks for reworking and resending this!

...

Quoted 7 lines

(quoted diff) +7 -0

+static int __init chunk_heap_init(void)
+{
+       struct cma *default_cma = dev_get_cma_area(NULL);
+       struct dma_heap_export_info exp_info;
+       struct chunk_heap *chunk_heap;
+
+       if (!default_cma)

Review

Quoted 10 lines

(quoted diff) +10 -0

+               return 0;
+
+       chunk_heap = kzalloc(sizeof(*chunk_heap), GFP_KERNEL);
+       if (!chunk_heap)
+               return -ENOMEM;
+
+       chunk_heap->order = CHUNK_HEAP_ORDER;
+       chunk_heap->cma = default_cma;
+
+       exp_info.name = cma_get_name(default_cma);

So, this would create a chunk heap name with the default CMA name, which would be indistinguishable from the heap name used for the plain CMA heap.

Quoted 5 lines

Quoted 2 lines

Probably a good idea to prefix it with "chunk-" so the heap device names are unique?

That will give an impression to user that they are using different CMA area but that's not true. IMHO, let's be honest at this moment.

I disagree. The dmabuf heaps provide an abstraction for allocating a type of memory, and while your heap is pulling from CMA, you aren't "just" allocating CMA as the existing CMA heap would suffice for that.

Since you need a slightly different method to allocate high order pages in bulk, we really should have a unique way to name the allocator interface. That's why I'd suggest the "chunk-" prefix to the heap name.

Quoted 35 lines · John Stultz

Quoted 28 lines · Minchan Kim

Quoted 27 lines · John Stultz

On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim <[email protected]> wrote:

Thanks for reworking and resending this!

...

Quoted 7 lines

(quoted diff) +7 -0

+static int __init chunk_heap_init(void)
+{
+       struct cma *default_cma = dev_get_cma_area(NULL);
+       struct dma_heap_export_info exp_info;
+       struct chunk_heap *chunk_heap;
+
+       if (!default_cma)

Review

Quoted 10 lines

(quoted diff) +10 -0

+               return 0;
+
+       chunk_heap = kzalloc(sizeof(*chunk_heap), GFP_KERNEL);
+       if (!chunk_heap)
+               return -ENOMEM;
+
+       chunk_heap->order = CHUNK_HEAP_ORDER;
+       chunk_heap->cma = default_cma;
+
+       exp_info.name = cma_get_name(default_cma);

So, this would create a chunk heap name with the default CMA name, which would be indistinguishable from the heap name used for the plain CMA heap.

Quoted 5 lines

Quoted 2 lines

Probably a good idea to prefix it with "chunk-" so the heap device names are unique?

That will give an impression to user that they are using different CMA area but that's not true. IMHO, let's be honest at this moment.

Quoted 8 lines

I disagree. The dmabuf heaps provide an abstraction for allocating a type of memory, and while your heap is pulling from CMA, you aren't "just" allocating CMA as the existing CMA heap would suffice for that.

Since you need a slightly different method to allocate high order pages in bulk, we really should have a unique way to name the allocator interface. That's why I'd suggest the "chunk-" prefix to the heap name.

Got it. How about this?

drivers/dma-buf/heaps/chunk_heap.c +0 -0

index 0277707a93a9..36e189d0b73d 100644

Quoted 53 lines · Minchan Kim

Quoted 35 lines · John Stultz

Quoted 28 lines · Minchan Kim

Quoted 27 lines · John Stultz

On Tue, Dec 1, 2020 at 9:51 AM Minchan Kim <[email protected]> wrote:

Thanks for reworking and resending this!

...

Quoted 7 lines

(quoted diff) +7 -0

+static int __init chunk_heap_init(void)
+{
+       struct cma *default_cma = dev_get_cma_area(NULL);
+       struct dma_heap_export_info exp_info;
+       struct chunk_heap *chunk_heap;
+
+       if (!default_cma)

Review

Quoted 10 lines

(quoted diff) +10 -0

+               return 0;
+
+       chunk_heap = kzalloc(sizeof(*chunk_heap), GFP_KERNEL);
+       if (!chunk_heap)
+               return -ENOMEM;
+
+       chunk_heap->order = CHUNK_HEAP_ORDER;
+       chunk_heap->cma = default_cma;
+
+       exp_info.name = cma_get_name(default_cma);

So, this would create a chunk heap name with the default CMA name, which would be indistinguishable from the heap name used for the plain CMA heap.

Quoted 5 lines

Quoted 2 lines

Probably a good idea to prefix it with "chunk-" so the heap device names are unique?

That will give an impression to user that they are using different CMA area but that's not true. IMHO, let's be honest at this moment.

Quoted 8 lines

I disagree. The dmabuf heaps provide an abstraction for allocating a type of memory, and while your heap is pulling from CMA, you aren't "just" allocating CMA as the existing CMA heap would suffice for that.

Since you need a slightly different method to allocate high order pages in bulk, we really should have a unique way to name the allocator interface. That's why I'd suggest the "chunk-" prefix to the heap name.

Got it. How about this?

drivers/dma-buf/heaps/chunk_heap.c +0 -0

index 0277707a93a9..36e189d0b73d 100644

drivers/dma-buf/heaps/chunk_heap.c static int __init chunk_heap_init(void) · line 413

Quoted 5 lines

drivers/dma-buf/heaps/chunk_heap.c +1 -1

@@ -410,7 +410,7 @@ static int __init chunk_heap_init(void)
        chunk_heap->order = CHUNK_HEAP_ORDER;
        chunk_heap->cma = default_cma;
 
-       exp_info.name = cma_get_name(default_cma);
+       exp_info.name = "cma-chunk-heap";

That's still a bit general for the default cma (which can be named differently). I think including cma name is important, just adding the chunk prefix might be best.

So something like
sprintf(buf, "chunk-%s", cma_get_name(default_cma)); exp_info.name = buf;

From: Hyesoo Yu <[email protected]>

This patch supports chunk heap that allocates the buffers that arranged into a list a fixed size chunks taken from CMA.

The chunk heap doesn't use heap-helper although it can remove duplicated code since heap-helper is under deprecated process.[1]

NOTE: This patch only adds the default CMA heap to allocate chunk pages. We will add another CMA memory regions to the dmabuf heaps interface with a later patch (which requires a dt binding)

+ * ION Memory Allocator chunk heap exporter