[next-6.6]Hygon: Enable the concurrent memory allocation of CMA for Hygon CSV3 · Pull Request !172 · OpenCloudOS/OpenCloudOS-Kernel

When multiple CSV3 virtual machines are launched at the same time, memory needs to be concurrently allocated from CMA to improve the concurrent startup performance of multiple CSV3 virtual machines. Whether cma_mutex lock is used for CMA allocation concurrency is modified several times back and forth on linux mainline. The most recent change is to add cma_mutex lock back, because when the cma memory is small (128MB) and the pageblock MAX_ORDER_NR_PAGES is large (32MB), only four cma slots are available in the test case. Without cma_mutex lock, dma_alloc_coherent would fail in the concurrent scenario.

----
Revert "mm/cma.c: remove redundant cma_mutex lock"
This reverts commit a4efc174b382fcdb which introduced a regression issue
that when there're multiple processes allocating dma memory in parallel by
calling dma_alloc_coherent(), it may fail sometimes as follows:

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.

When 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: 784kB (UECI) 17728kB (UMECI) 133516kB (UMECI) 36032kB (UMECI) 6564kB (UMCI)
36128kB (UMECI) 16256kB (UMCI) 6512kB (EI) 81024kB (UEI) 42048kB (MI) 84096kB (EI)
88192kB (UI) 316384kB (EI) 832768kB (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 memory range process A trying to alloc
has already been isolated by the allocation of process B during memory
migration.

The problem here is that the memory range isolated during one allocation
by start_isolate_page_range() could be much bigger than the real size we
want to alloc due to the range is aligned to MAX_ORDER_NR_PAGES.

Taking an ARMv7 platform with 1G memory as an example, when
MAX_ORDER_NR_PAGES is big (e.g. 32M with max_order 14) and CMA memory is
relatively small (e.g. 128M), there're only 4 MAX_ORDER slot, then it's
very easy that all CMA memory may have already been isolated by other
processes when one trying to allocate memory using dma_alloc_coherent().
Since current CMA code will only scan one time of whole available CMA
memory, then dma_alloc_coherent() may easy fail due to contention with
other processes.

This patch simply falls back to the original method that using cma_mutex
to make alloc_contig_range() run sequentially to avoid the issue.

Link: https://lkml.kernel.org/r/20220509094551.3596244-1-aisheng.dong@nxp.com
Link: https://lore.kernel.org/all/20220315144521.3810298-2-aisheng.dong@nxp.com/
Fixes: a4efc174b382 ("mm/cma.c: remove redundant cma_mutex lock")
Signed-off-by: Dong Aisheng aisheng.dong@nxp.com
Acked-by: Minchan Kim minchan@kernel.org
Acked-by: David Hildenbrand david@redhat.com
Cc: Marek Szyprowski m.szyprowski@samsung.com
Cc: Lecopzer Chen lecopzer.chen@mediatek.com
Cc: Vlastimil Babka vbabka@suse.cz
Cc: stable@vger.kernel.org [5.11+]
Signed-off-by: Andrew Morton akpm@linux-foundation.org

Type	Assign personnel	Status
Reviewer	chinaljp030 刘诗	Completed (0/0 )
Tester	chinaljp030 刘诗	Completed (0/0 )

GVPOpenCloudOS/OpenCloudOS-Kernel

Search

GVP OpenCloudOS/OpenCloudOS-Kernel