On Wed, May 22, 2019 at 8:41 AM Paolo Pisati <[email protected]> wrote:
>
> I realize this is just a workaround (and the above 31M cma memory
> fragmentation is ugly), but we should definitely bump CMA allocation
> space: definitely 32M (since that's what upstream default to) but if 64M
> solves a problem you have at the moment (until we sort out the driver
> issue), i'm not opposing to such a change -
Unfortunately, without other mitigations, we blow past 64M as well.
Ignoring fragmentation, we're using ~108M of CMA (summing up the
totals in comment #11). I think including the dma-contiguous patches
are key. They would alleviate the pain of the single page allocations
(~46M), and unblock driver optimizations from doing the same (hisi_sas
driver could move 33M of allocs out of CMA). Those would impact archs
that have CONFIG_DMA_CMA, which are arm64 and armhf-generic:
debian.master/config/annotations:CONFIG_DMA_CMA
policy<{'amd64': 'n', 'arm64': 'y', 'armhf-generic': 'y',
'armhf-generic-lpae': 'n', 'i386': 'n', 's390x': 'n'}>
I don't have any real armhf-generic hw anymore - if I prepared PPA
kernels, would you happen to have kit for regression testing?
> after all, you are the main
> consumer of generic/arm64 (all other boards are either armhf or have
> their own topic kernel) so if there's a workaround we can apply to make
> your life easier, i don't see why we shouldn't do it.
My biggest concern w/ bumping up CMA is that we do appear to have
users of the arm64/generic kernel on platforms I don't have. For
instance, the reason we got into this CMA issue at all was by turning
on DMA_CMA on arm64 for the RPi3 (bug 1803206) - so I'd at least like
to get some regression testing on that platform. And, obviously such
relatively lowmem platforms make me want to be rather conservative
about bumping up CMA sizes.
-dann
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1823753
Title:
arm64: cma_alloc errors at boot
Status in linux package in Ubuntu:
Confirmed
Bug description:
On some arm64 systems[*] we are seeing a spew of messages on the
console:
[ 19.534097] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12
[ 19.534109] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12
[ 19.534113] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12
[ 19.534126] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12
[ 19.534130] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12
[ 19.534142] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12
[ 19.534146] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12
[ 19.534157] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12
[ 19.534161] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12
[ 19.534173] cma: cma_alloc: alloc failed, req-size: 16 pages, ret: -12
[ 19.534177] cma: cma_alloc: alloc failed, req-size: 64 pages, ret: -12
This appears to be non-fatal - impacted systems all eventually boot.
But, at least in the case of the HP m400, it slows down boot enough
that MAAS' default timeout will expire before completing deployment.
[*] Observed on a HiSilicon D06 w/ SMMU disabled in the BIOS, as well
as an HP m400 (APM X-Gene) cartridge - although, not on another one
that - in theory - should be identical.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823753/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
