linux-kernel - PFNs busy - CMA memory stolen from percpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4e73ec8a-0851-8177-b1d8-f2c1ef884795@gmail.com>
Date:   Tue, 17 Oct 2017 16:27:37 +0200
From:   Rafal <fatwildcat@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: PFNs busy - CMA memory stolen from percpu

I have an arm64 board which uses cma allocator for VPU (NanoPi M3). It 
has 96MB of cma-reserved memory and sometimes cma allocation fails, 
despite the memory amount was set with some reserve. Moreover, higher 
memory reserve helps only to some extent. With 256MB of cma memory the 
system encounters many "PFNs busy" messages in kernel log and overall 
slowdown at video startup.

I have made some investigations. It looks that usual migratable 
allocations steal plenty of cma memory from per-cpu pool, for e.g. 
shared memory, despite there is a lot of "normal" (non-cma) memory which 
might be used for that. Most of the memory is given back when a new cma 
allocation is made, but some (rare) pages aren't reclaimed and result 
with the "PFNs busy" messages. Please imagine: even if one page per 100 
is not reclaimed, it is a problem for contiguous HD video buffers 
allocation, about 2MB each.

I have made a test: I have added drain_all_pages() function call at end 
of free_contig_range() call. The "PFNs busy" messages disappeared 
completely and video playing is started more fluently. So, I'm wondering 
whether cma pages should be really mixed with usual migratable pages in 
percpu pool?

Rafal