linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dong Aisheng <aisheng.dong@nxp.com>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, dongas86@gmail.com,
	linux-arm-kernel@lists.infradead.org, jason.hui.liu@nxp.com,
	leoyang.li@nxp.com, abel.vesa@nxp.com, shawnguo@kernel.org,
	linux-imx@nxp.com, akpm@linux-foundation.org,
	m.szyprowski@samsung.com, lecopzer.chen@mediatek.com,
	david@redhat.com, vbabka@suse.cz, stable@vger.kernel.org,
	shijie.qin@nxp.com, Dong Aisheng <aisheng.dong@nxp.com>
Subject: [PATCH 2/2] mm: cma: try next pageblock during retry
Date: Wed, 15 Dec 2021 16:02:42 +0800	[thread overview]
Message-ID: <20211215080242.3034856-3-aisheng.dong@nxp.com> (raw)
In-Reply-To: <20211215080242.3034856-1-aisheng.dong@nxp.com>

On an ARMv7 platform with 32M pageblock(MAX_ORDER 14), we observed a
huge number of retries of CMA allocation (1k+) during booting when
allocating one page for each of 3 mmc instance probe.

This is caused by CMA now supports cocurrent allocation since commit
a4efc174b382 ("mm/cma.c: remove redundant cma_mutex lock").
The pageblock we tried to allocate may have already been
acquired and isolated by others, then cma_alloc() will retry the next
area of the same size by bitmap_no + mask + 1. However, the pageblock
order could be big and pageblock_nr_pages is huge (e.g. 8192),
then keep retrying in a small step become meaningless because
it's likely known to fail again due to within the same pageblock.

Instread of looping in the same pageblock and wasting CPU
mips, especially for big pageblock system (e.g. 16M or 32M),
we try the next pageblock directly.

Doing this way can greatly mitigate the situtation.

Below is the original error log during booting:
[    2.004804] cma: cma_alloc(cma (ptrval), count 1, align 0)
[    2.010318] cma: cma_alloc(cma (ptrval), count 1, align 0)
[    2.010776] cma: cma_alloc(): memory range at (ptrval) is busy, retrying
[    2.010785] cma: cma_alloc(): memory range at (ptrval) is busy, retrying
[    2.010793] cma: cma_alloc(): memory range at (ptrval) is busy, retrying
[    2.010800] cma: cma_alloc(): memory range at (ptrval) is busy, retrying
[    2.010807] cma: cma_alloc(): memory range at (ptrval) is busy, retrying
[    2.010814] cma: cma_alloc(): memory range at (ptrval) is busy, retrying
.... (+1K retries)

After fix, the 1200+ reties can be reduced to 0.
Another test running 8 VPU decoder in parallel shows that 1500+ retries
dropped to ~145.

IOW this patch can improve the CMA allocation speed a lot when there're
enough CMA memory by reducing retries significantly.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Lecopzer Chen <lecopzer.chen@mediatek.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
CC: stable@vger.kernel.org # 5.11+
Fixes: a4efc174b382 ("mm/cma.c: remove redundant cma_mutex lock")
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
 mm/cma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/cma.c b/mm/cma.c
index 1c13a729d274..108a1ceacbe7 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -500,7 +500,9 @@ struct page *cma_alloc(struct cma *cma, unsigned long count,
 		trace_cma_alloc_busy_retry(cma->name, pfn, pfn_to_page(pfn),
 					   count, align);
 		/* try again with a bit different memory target */
-		start = bitmap_no + mask + 1;
+		start = ALIGN(bitmap_no + mask + 1,
+			      pageblock_nr_pages >> cma->order_per_bit);
+
 	}
 
 	trace_cma_alloc_finish(cma->name, pfn, page, count, align);
-- 
2.25.1



      parent reply	other threads:[~2021-12-15  8:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15  8:02 [PATCH 0/2] mm: fix cma allocation fail sometimes Dong Aisheng
2021-12-15  8:02 ` [PATCH 1/2] mm: cma: fix allocation may " Dong Aisheng
2021-12-15 12:30   ` David Hildenbrand
2021-12-16  2:54     ` Aisheng Dong
2021-12-16 10:56       ` David Hildenbrand
2021-12-17  3:44         ` Aisheng Dong
2021-12-17 12:27           ` David Hildenbrand
2021-12-20  3:43             ` Dong Aisheng
2021-12-15  8:02 ` Dong Aisheng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211215080242.3034856-3-aisheng.dong@nxp.com \
    --to=aisheng.dong@nxp.com \
    --cc=abel.vesa@nxp.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=dongas86@gmail.com \
    --cc=jason.hui.liu@nxp.com \
    --cc=lecopzer.chen@mediatek.com \
    --cc=leoyang.li@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=shawnguo@kernel.org \
    --cc=shijie.qin@nxp.com \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox