question for cma alloc fail issue

question for cma alloc fail issue

[Jared Hu]

Hi All，

We are facing a cma memory alloc issue on linux 4.14.98 and lower version.

In our platform imx8m, we using cma to allocate large continuous memory
block to support zero-copy between video decode and display sub-system.
But after long time loop video playback test, system will report alloc
cma fail ret=busy. We take a deep look into cma.c found there are still
some big free areas in cma->bitmap that maybe can alloc 3595 pages.

Here are some questions:
1. in __alloc_contig_migrate_range() cc->nr_migratepages always been 0
Does cc->nr_migratepages = 0 means there is no page can be reclaimed or
migrated? Which kind of pages that cannot been reclaimed.

2. The pages that are free in cma->bitmap seem not free in Buddy system?
PageBuddy() test can also return false even if the page is in the free list in cma bitmap
I test the fail page with page_is_file_cache(page) which return 0.
comment show: 0 if @page is anonymous, tmpfs or otherwise ram or swap backed.
What does swap backed mean? Which one maybe occupy these pages?

Could someone give me a favor to debug this issue?

Best regareds
Jared Hu

Re: question for cma alloc fail issue

[Matthew Wilcox]

On Wed, Apr 10, 2019 at 10:48:26AM +0000, Jared Hu wrote:
> 2. The pages that are free in cma->bitmap seem not free in Buddy system?
> PageBuddy() test can also return false even if the page is in the free list in cma bitmap

That's correct.  They've been allocated by the CMA allocator, and are no
longer available for allocation by the page allocator.

question for cma alloc fail issue

[Jared Hu]

[-- Attachment #1.1: Type: text/plain, Size: 2165 bytes --]

Hi All，

We are facing a cma memory alloc issue. In our platform imx8m, we using cma to allocate large continuous memory block to support zero-copy between video decode and display sub-system. But after long time loop video playback test, system will report alloc cma fail ret=busy.
We take a deep look into cma.c found there are still some big free areas in cma->bitmap that maybe can meet the required 3595 pages.

The question is pages that are free in cma->bitmap seem not free in Buddy system? Then which one maybe occupy these pages? We suspect these pages are file cache because if drop all cache, then this issue will not happen.

We have two clues as below:

1.     PageBuddy test fail even if the page is 0 in bitmap
Eg, page 117760 located in 10274@115678, PageBuddy() will return false as below log show:
multiqueue1542:-8444  [003] d..1 225233.624057: test_pages_isolated: pfn 0x60c00 pageBuddy return false
multiqueue1542:-8444  [003] d..1 225233.624058: test_pages_isolated: return pfn=0x60c00

below is the cma area bitmap summary when error occurs, there are still some big areas in yellow marks which can hold 3595 pages:
cma_alloc: alloc failed, req-size: 3595 pages, ret: -16
cma_alloc: number of available pages:
4@8420+18@8430+80@8880+129@74623+1023@78849+34@82910+6178@85982+34@95198+8226@98270+34@109534+34@112606
+10274@115678+1058@128990+34@133086+34@136158+2082@139230+9250@144350+34@156638+1570@159710+9762@164318
+2549@177675+19957@183819+5621@207371+12789@216587+245@232971+245@236811+245@240651+1269@244491 => 92812 free of 245760 total pages


2.     Meanwhile in debuf fs the free size is not aligned with that meminfo reported:
In debuf fs: 245760-138568=107192(pages) = 428768 kB
In /proc/meminfo: 296976 kB

root@imx8mqevk:~# cat /proc/meminfo | grep Cma*
CmaTotal:         983040 kB
CmaFree:          296976 kB
root@imx8mqevk:~# cat /sys/kernel/debug/cma/cma-linux,cma/count
245760
root@imx8mqevk:~# cat /sys/kernel/debug/cma/cma-linux,cma/used
138568

Could someone give me a favor to debug this issue?

Best regards
Jared Hu
Mobile: 86-15962100482
[cid:image002.png@01D131D7.ABC30730]

[-- Attachment #1.2: Type: text/html, Size: 10532 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 182 bytes --]

[-- Attachment #3: image002.png --]
[-- Type: image/png, Size: 22041 bytes --]