linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jared Hu <jared.hu@nxp.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: question for cma alloc fail issue
Date: Tue, 19 Mar 2019 08:31:37 +0000	[thread overview]
Message-ID: <DB7PR04MB55808491855429C48CE8CCF298400@DB7PR04MB5580.eurprd04.prod.outlook.com> (raw)


[-- 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 --]

             reply	other threads:[~2019-03-19  8:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-19  8:31 Jared Hu [this message]
2019-04-10 10:48 Jared Hu
2019-04-10 13:14 ` Matthew Wilcox

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=DB7PR04MB55808491855429C48CE8CCF298400@DB7PR04MB5580.eurprd04.prod.outlook.com \
    --to=jared.hu@nxp.com \
    --cc=linux-mm@kvack.org \
    /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