We observed an issue with NXP 5.15 LTS kernel that dma_alloc_coherent()
may fail sometimes when there're multiple processes trying to allocate
CMA memory.
This issue can be very easily reproduced on MX6Q SDB board with latest
linux-next kernel by writing a test module creating 16 or 32 threads
allocating random size of CMA memory in parallel at the background.
Or simply enabling CONFIG_CMA_DEBUG, you can see endless of CMA alloc
retries during booting:
[ 1.452124] cma: cma_alloc(): memory range at (ptrval) is busy,retrying
....
(thousands of reties)
NOTE: MX6 has CONFIG_FORCE_MAX_ZONEORDER=14 which means MAX_ORDER is
13 (32M).
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports concurrent
memory allocation.
It's possible that the pageblock process A try to alloc has already
been isolated by the allocation of process B during memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of the
whole available CMA bitmap.
This patchset introduces a retry mechanism to rescan CMA bitmap for -EBUSY
error in case the target pageblock may has been temporarily isolated
by others and released later.
It also improves the CMA allocation performance by trying the next
pageblock during reties rather than looping in the same pageblock
which is in -EBUSY state.
Theoretically, this issue can be easily reproduced on ARMv7 platforms
with big MAX_ORDER/pageblock
e.g. 1G RAM(320M reserved CMA) and 32M pageblock ARM platform:
Page block order: 13
Pages per block: 8192
The following test is based on linux-next: next-20211213.
Without the fix, it's easily fail.
# insmod cma_alloc.ko pnum=16
[ 274.322369] CMA alloc test enter: thread number: 16
[ 274.329948] cpu: 0, pid: 692, index 4 pages 144
[ 274.330143] cpu: 1, pid: 694, index 2 pages 44
[ 274.330359] cpu: 2, pid: 695, index 7 pages 757
[ 274.330760] cpu: 2, pid: 696, index 4 pages 144
[ 274.330974] cpu: 2, pid: 697, index 6 pages 512
[ 274.331223] cpu: 2, pid: 698, index 6 pages 512
[ 274.331499] cpu: 2, pid: 699, index 2 pages 44
[ 274.332228] cpu: 2, pid: 700, index 0 pages 7
[ 274.337421] cpu: 0, pid: 701, index 1 pages 38
[ 274.337618] cpu: 2, pid: 702, index 0 pages 7
[ 274.344669] cpu: 1, pid: 703, index 0 pages 7
[ 274.344807] cpu: 3, pid: 704, index 6 pages 512
[ 274.348269] cpu: 2, pid: 705, index 5 pages 148
[ 274.349490] cma: cma_alloc: reserved: alloc failed, req-size: 38 pages, ret: -16
[ 274.366292] cpu: 1, pid: 706, index 4 pages 144
[ 274.366562] cpu: 0, pid: 707, index 3 pages 128
[ 274.367356] cma: cma_alloc: reserved: alloc failed, req-size: 128 pages, ret: -16
[ 274.367370] cpu: 0, pid: 707, index 3 pages 128 failed
[ 274.371148] cma: cma_alloc: reserved: alloc failed, req-size: 148 pages, ret: -16
[ 274.375348] cma: cma_alloc: reserved: alloc failed, req-size: 144 pages, ret: -16
[ 274.384256] cpu: 2, pid: 708, index 0 pages 7
....
With the fix, 32 threads allocating in parallel can pass overnight
stress test.
root@imx6qpdlsolox:~# insmod cma_alloc.ko pnum=32
[ 112.976809] cma_alloc: loading out-of-tree module taints kernel.
[ 112.984128] CMA alloc test enter: thread number: 32
[ 112.989748] cpu: 2, pid: 707, index 6 pages 512
[ 112.994342] cpu: 1, pid: 708, index 6 pages 512
[ 112.995162] cpu: 0, pid: 709, index 3 pages 128
[ 112.995867] cpu: 2, pid: 710, index 0 pages 7
[ 112.995910] cpu: 3, pid: 711, index 2 pages 44
[ 112.996005] cpu: 3, pid: 712, index 7 pages 757
[ 112.996098] cpu: 3, pid: 713, index 7 pages 757
...
[41877.368163] cpu: 1, pid: 737, index 2 pages 44
[41877.369388] cpu: 1, pid: 736, index 3 pages 128
[41878.486516] cpu: 0, pid: 737, index 2 pages 44
[41878.486515] cpu: 2, pid: 739, index 4 pages 144
[41878.486622] cpu: 1, pid: 736, index 3 pages 128
[41878.486948] cpu: 2, pid: 735, index 7 pages 757
[41878.487279] cpu: 2, pid: 738, index 4 pages 144
[41879.526603] cpu: 1, pid: 739, index 3 pages 128
[41879.606491] cpu: 2, pid: 737, index 3 pages 128
[41879.606550] cpu: 0, pid: 736, index 0 pages 7
[41879.612271] cpu: 2, pid: 738, index 4 pages 144
...
Dong Aisheng (2):
mm: cma: fix allocation may fail sometimes
mm: cma: try next pageblock during retry
mm/cma.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16
cma: number of available pages:
3@125+20@172+12@236+4@380+32@736+17@2287+23@2473+20@36076+99@40477+108@40852+44@41108+20@41196+108@41364+108@41620+
108@42900+108@43156+483@44061+1763@45341+1440@47712+20@49324+20@49388+5076@49452+2304@55040+35@58141+20@58220+20@58284+
7188@58348+84@66220+7276@66452+227@74525+6371@75549=> 33161 free of 81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free CMA
memory and a lot available free slots for 148 pages in CMA bitmap that we
want to allocate.
If dumping memory info, we found that there was also ~342M normal memory,
but only 1352K CMA memory left in buddy system while a lot of pageblocks
were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB
active_anon:98060kB inactive_anon:98948kB active_file:60864kB inactive_file:31776kB
unevictable:0kB writepending:0kB present:1048576kB managed:1018328kB mlocked:0kB
bounce:0kB free_pcp:220kB local_pcp:192kB free_cma:1352kB lowmem_reserve[]: 0 0 0
Normal: 78*4kB (UECI) 1772*8kB (UMECI) 1335*16kB (UMECI) 360*32kB (UMECI) 65*64kB (UMCI)
36*128kB (UMECI) 16*256kB (UMCI) 6*512kB (EI) 8*1024kB (UEI) 4*2048kB (MI) 8*4096kB (EI)
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports concurrent
memory allocation. It's possible that the pageblock process A try to alloc
has already been isolated by the allocation of process B during memory
migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of the
whole available CMA bitmap.
This patch introduces a retry mechanism to rescan CMA bitmap for -EBUSY
error in case the target pageblock may has been temporarily isolated
by others and released later.
Theoretically, this issue can be easily reproduced on ARMv7 platforms
with big MAX_ORDER/pageblock
e.g. 1G RAM(320M reserved CMA) and 32M pageblock ARM platform:
Page block order: 13
Pages per block: 8192
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Lecopzer Chen <redacted>
Cc: David Hildenbrand <redacted>
Cc: Vlastimil Babka <redacted>
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 | 11 +++++++++++
1 file changed, 11 insertions(+)
From: David Hildenbrand <hidden> Date: 2021-12-15 12:30:59
On 15.12.21 09:02, Dong Aisheng wrote:
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16
cma: number of available pages:
3@125+20@172+12@236+4@380+32@736+17@2287+23@2473+20@36076+99@40477+108@40852+44@41108+20@41196+108@41364+108@41620+
108@42900+108@43156+483@44061+1763@45341+1440@47712+20@49324+20@49388+5076@49452+2304@55040+35@58141+20@58220+20@58284+
7188@58348+84@66220+7276@66452+227@74525+6371@75549=> 33161 free of 81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free CMA
memory and a lot available free slots for 148 pages in CMA bitmap that we
want to allocate.
If dumping memory info, we found that there was also ~342M normal memory,
but only 1352K CMA memory left in buddy system while a lot of pageblocks
were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB reserved_highatomic:0KB
active_anon:98060kB inactive_anon:98948kB active_file:60864kB inactive_file:31776kB
unevictable:0kB writepending:0kB present:1048576kB managed:1018328kB mlocked:0kB
bounce:0kB free_pcp:220kB local_pcp:192kB free_cma:1352kB lowmem_reserve[]: 0 0 0
Normal: 78*4kB (UECI) 1772*8kB (UMECI) 1335*16kB (UMECI) 360*32kB (UMECI) 65*64kB (UMCI)
36*128kB (UMECI) 16*256kB (UMCI) 6*512kB (EI) 8*1024kB (UEI) 4*2048kB (MI) 8*4096kB (EI)
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports concurrent
memory allocation. It's possible that the pageblock process A try to alloc
has already been isolated by the allocation of process B during memory
migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of the
whole available CMA bitmap.
I already raised in different context that we should most probably
convert that -EBUSY to -EAGAIN -- to differentiate an actual migration
problem from a simple "concurrent allocations that target the same
MAX_ORDER -1 range".
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: David Hildenbrand <redacted>
Sent: Wednesday, December 15, 2021 8:31 PM
On 15.12.21 09:02, Dong Aisheng wrote:
quoted
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16
cma: number of available pages:
81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free
CMA memory and a lot available free slots for 148 pages in CMA bitmap
that we want to allocate.
If dumping memory info, we found that there was also ~342M normal
memory, but only 1352K CMA memory left in buddy system while a lot of
pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports
concurrent
quoted
memory allocation. It's possible that the pageblock process A try to
alloc has already been isolated by the allocation of process B during
memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of the
whole available CMA bitmap.
I already raised in different context that we should most probably convert that
-EBUSY to -EAGAIN -- to differentiate an actual migration problem from a
simple "concurrent allocations that target the same MAX_ORDER -1 range".
Thanks for the info. Is there a patch under review?
BTW i wonder that probably makes no much difference for my patch since we may
prefer retry the next pageblock rather than busy waiting on the same isolated pageblock.
Otherwise, we may meet the same issue as the patch 2/2 wants to address.
How do you think?
Regards
Aisheng
From: David Hildenbrand <hidden> Date: 2021-12-16 10:57:06
On 16.12.21 03:54, Aisheng Dong wrote:
quoted
From: David Hildenbrand <redacted>
Sent: Wednesday, December 15, 2021 8:31 PM
On 15.12.21 09:02, Dong Aisheng wrote:
quoted
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret: -16
cma: number of available pages:
81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free
CMA memory and a lot available free slots for 148 pages in CMA bitmap
that we want to allocate.
If dumping memory info, we found that there was also ~342M normal
memory, but only 1352K CMA memory left in buddy system while a lot of
pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports
concurrent
quoted
memory allocation. It's possible that the pageblock process A try to
alloc has already been isolated by the allocation of process B during
memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of the
whole available CMA bitmap.
I already raised in different context that we should most probably convert that
-EBUSY to -EAGAIN -- to differentiate an actual migration problem from a
simple "concurrent allocations that target the same MAX_ORDER -1 range".
Thanks for the info. Is there a patch under review?
No, and I was too busy for now to send it out.
BTW i wonder that probably makes no much difference for my patch since we may
prefer retry the next pageblock rather than busy waiting on the same isolated pageblock.
Makes sense. BUT as of now we isolate not only a pageblock but a
MAX_ORDER -1 page (e.g., 2 pageblocks on x86-64 (!) ). So you'll have
the same issue in that case.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: David Hildenbrand <redacted>
Sent: Thursday, December 16, 2021 6:57 PM
On 16.12.21 03:54, Aisheng Dong wrote:
quoted
quoted
From: David Hildenbrand <redacted>
Sent: Wednesday, December 15, 2021 8:31 PM
On 15.12.21 09:02, Dong Aisheng wrote:
quoted
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret:
-16
cma: number of available pages:
81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free
CMA memory and a lot available free slots for 148 pages in CMA
bitmap that we want to allocate.
If dumping memory info, we found that there was also ~342M normal
memory, but only 1352K CMA memory left in buddy system while a lot
of pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports
concurrent
quoted
memory allocation. It's possible that the pageblock process A try to
alloc has already been isolated by the allocation of process B
during memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of
the whole available CMA bitmap.
I already raised in different context that we should most probably
convert that -EBUSY to -EAGAIN -- to differentiate an actual
migration problem from a simple "concurrent allocations that target the
same MAX_ORDER -1 range".
quoted
quoted
Thanks for the info. Is there a patch under review?
No, and I was too busy for now to send it out.
quoted
BTW i wonder that probably makes no much difference for my patch since
we may prefer retry the next pageblock rather than busy waiting on the
same isolated pageblock.
Makes sense. BUT as of now we isolate not only a pageblock but a
MAX_ORDER -1 page (e.g., 2 pageblocks on x86-64 (!) ). So you'll have the
same issue in that case.
Yes, should I change to try next MAX_ORDER_NR_PAGES or keep as it is
and let the core to improve it later?
I saw there's a patchset under review which is going to remove the
MAX_ORDER - 1 alignment requirement for CMA.
https://patchwork.kernel.org/project/linux-mm/cover/20211209230414.2766515-1-zi.yan@sent.com/
Once it's merged, I guess we can back to align with pageblock rather
than MAX_ORDER-1.
Regards
Aisheng
From: David Hildenbrand <hidden> Date: 2021-12-17 12:27:17
On 17.12.21 04:44, Aisheng Dong wrote:
quoted
From: David Hildenbrand <redacted>
Sent: Thursday, December 16, 2021 6:57 PM
On 16.12.21 03:54, Aisheng Dong wrote:
quoted
quoted
From: David Hildenbrand <redacted>
Sent: Wednesday, December 15, 2021 8:31 PM
On 15.12.21 09:02, Dong Aisheng wrote:
quoted
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret:
-16
cma: number of available pages:
81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free
CMA memory and a lot available free slots for 148 pages in CMA
bitmap that we want to allocate.
If dumping memory info, we found that there was also ~342M normal
memory, but only 1352K CMA memory left in buddy system while a lot
of pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports
concurrent
quoted
memory allocation. It's possible that the pageblock process A try to
alloc has already been isolated by the allocation of process B
during memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of
the whole available CMA bitmap.
I already raised in different context that we should most probably
convert that -EBUSY to -EAGAIN -- to differentiate an actual
migration problem from a simple "concurrent allocations that target the
same MAX_ORDER -1 range".
quoted
quoted
Thanks for the info. Is there a patch under review?
No, and I was too busy for now to send it out.
quoted
BTW i wonder that probably makes no much difference for my patch since
we may prefer retry the next pageblock rather than busy waiting on the
same isolated pageblock.
Makes sense. BUT as of now we isolate not only a pageblock but a
MAX_ORDER -1 page (e.g., 2 pageblocks on x86-64 (!) ). So you'll have the
same issue in that case.
Yes, should I change to try next MAX_ORDER_NR_PAGES or keep as it is
and let the core to improve it later?
I saw there's a patchset under review which is going to remove the
MAX_ORDER - 1 alignment requirement for CMA.
https://patchwork.kernel.org/project/linux-mm/cover/20211209230414.2766515-1-zi.yan@sent.com/
Once it's merged, I guess we can back to align with pageblock rather
than MAX_ORDER-1.
While the goal is to get rid of the alignment requirement, we might
still have to isolate all applicable MAX_ORDER-1 pageblocks. Depends on
what we can or cannot achieve easily :)
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Dec 17, 2021 at 8:27 PM David Hildenbrand [off-list ref] wrote:
On 17.12.21 04:44, Aisheng Dong wrote:
quoted
quoted
From: David Hildenbrand <redacted>
Sent: Thursday, December 16, 2021 6:57 PM
On 16.12.21 03:54, Aisheng Dong wrote:
quoted
quoted
From: David Hildenbrand <redacted>
Sent: Wednesday, December 15, 2021 8:31 PM
On 15.12.21 09:02, Dong Aisheng wrote:
quoted
We met dma_alloc_coherent() fail sometimes when doing 8 VPU decoder
test in parallel on a MX6Q SDB board.
Error log:
cma: cma_alloc: linux,cma: alloc failed, req-size: 148 pages, ret:
-16
cma: number of available pages:
81920 total pages
When issue happened, we saw there were still 33161 pages (129M) free
CMA memory and a lot available free slots for 148 pages in CMA
bitmap that we want to allocate.
If dumping memory info, we found that there was also ~342M normal
memory, but only 1352K CMA memory left in buddy system while a lot
of pageblocks were isolated.
Memory info log:
Normal free:351096kB min:30000kB low:37500kB high:45000kB
8*8192kB (UI) 3*16384kB (EI) 8*32768kB (M) = 489288kB
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports
concurrent
quoted
memory allocation. It's possible that the pageblock process A try to
alloc has already been isolated by the allocation of process B
during memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of
the whole available CMA bitmap.
I already raised in different context that we should most probably
convert that -EBUSY to -EAGAIN -- to differentiate an actual
migration problem from a simple "concurrent allocations that target the
same MAX_ORDER -1 range".
quoted
quoted
Thanks for the info. Is there a patch under review?
No, and I was too busy for now to send it out.
quoted
BTW i wonder that probably makes no much difference for my patch since
we may prefer retry the next pageblock rather than busy waiting on the
same isolated pageblock.
Makes sense. BUT as of now we isolate not only a pageblock but a
MAX_ORDER -1 page (e.g., 2 pageblocks on x86-64 (!) ). So you'll have the
same issue in that case.
Yes, should I change to try next MAX_ORDER_NR_PAGES or keep as it is
and let the core to improve it later?
I saw there's a patchset under review which is going to remove the
MAX_ORDER - 1 alignment requirement for CMA.
https://patchwork.kernel.org/project/linux-mm/cover/20211209230414.2766515-1-zi.yan@sent.com/
Once it's merged, I guess we can back to align with pageblock rather
than MAX_ORDER-1.
While the goal is to get rid of the alignment requirement, we might
still have to isolate all applicable MAX_ORDER-1 pageblocks. Depends on
what we can or cannot achieve easily :)
Ok, got it. As that's another story and does not affect us to fix the current
kernel problem first that CMA alloc may fail occasionally,
I'm going to change to align with MAX_ORDER_NR_PAGES for retries
as you pointed out in the next version.
Do you have more suggestions for this patchset?
Regards
Aisheng
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 <redacted>
Cc: David Hildenbrand <redacted>
Cc: Vlastimil Babka <redacted>
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(-)
@@ -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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel