vc4: Increased CMA usage after replace drm_gem_dma_object for drm_gem_object in vc4_exec_info
Stefan Wahren
wahrenst at gmx.net
Fri Jul 5 16:17:10 UTC 2024
Hi,
Am 05.07.24 um 17:19 schrieb Daniel Vetter:
> Adding dri-devel
>
> On Fri, 5 Jul 2024 at 17:14, Stefan Wahren <wahrenst at gmx.net> wrote:
>
> Hi,
> last year my Raspberry Pi 3B Plus died, so i didn't noticed this
> sooner.
> If I ran Raspberry Pi OS Bullseye with X11 and a recent Mainline
> Kernel
> (arm/multi_v7_defconfig) on my new Raspberry Pi 3 B+, i'm getting the
> following errors:
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 6.10.0-rc1-g685505219723
> (stefanw at stefanw-SCHENKER) (arm-linux-gnueabihf-gcc (GCC) 11.3.1
> 20220604 [releases/gcc-11 revision
> 591c0f4b92548e3ae2e8173f4f93984b1c7f62bb], GNU ld
> (Linaro_Binutils-2022.06) 2.37.20220122) #1 SMP Wed Jul 3
> 19:57:14 CEST
> 2024
> [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7),
> cr=10c5383d
> [ 0.000000] CPU: div instructions available: patching division code
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus
> Rev 1.3
> [ 0.000000] random: crng init done
> [ 0.000000] Memory policy: Data cache writealloc
> [ 0.000000] efi: UEFI not found.
> [ 0.000000] Reserved memory: created CMA memory pool at 0x37000000,
> size 64 MiB
> [ 0.000000] OF: reserved mem: initialized node linux,cma,
> compatible
> id shared-dma-pool
> [ 0.000000] OF: reserved mem: 0x37000000..0x3affffff (65536
> KiB) map
> reusable linux,cma
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff]
> [ 0.000000] Normal empty
> [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003b3fffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x000000003b3fffff]
> [ 0.000000] Initmem setup node 0 [mem
> 0x0000000000000000-0x000000003b3fffff]
> [ 0.000000] percpu: Embedded 17 pages/cpu s40404 r8192 d21036
> u69632
> [ 0.000000] pcpu-alloc: s40404 r8192 d21036 u69632 alloc=17*4096
> [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [ 0.000000] Kernel command line: video=HDMI-A-1:1920x1200M at 60
> dma.dmachans=0x7ff5 bcm2709.boardrev=0xa020d3
> bcm2709.serial=0x51972538
> bcm2709.uart_clock=48000000 bcm2709.disk_led_gpio=29
> bcm2709.disk_led_active_low=0 vc_mem.mem_base=0x3ec00000
> vc_mem.mem_size=0x40000000 console=ttyS1,115200 console=tty1
> root=PARTUUID=ecfed651-02 rootfstype=ext4 fsck.repair=yes rootwait
> [ 0.000000] Dentry cache hash table entries: 131072 (order: 7,
> 524288
> bytes, linear)
> [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes, linear)
> [ 0.000000] Built 1 zonelists, mobility grouping on. Total
> pages: 242688
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap
> free:off,
> mlocked free:off
> [ 0.000000] Memory: 868880K/970752K available (15360K kernel code,
> 2535K rwdata, 6708K rodata, 2048K init, 426K bss, 36336K reserved,
> 65536K cma-reserved, 118784K highmem)
> ...
> [ 56.187787] [drm:vc4_bo_create [vc4]] *ERROR* Failed to
> allocate from
> GEM DMA helper:
> [ 56.187870] vc4-drm soc:gpu: [drm] V3D: 36316kb BOs (40)
> [ 56.187884] vc4-drm soc:gpu: [drm] V3D shader:
> 124kb BOs (31)
> [ 56.187893] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5)
> [ 56.187900] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> [ 56.187909] vc4-drm soc:gpu: [drm] total purged BO:
> 19540kb BOs (15)
> [ 56.188269] [drm:vc4_bo_create [vc4]] *ERROR* Failed to
> allocate from
> GEM DMA helper:
> [ 56.188315] vc4-drm soc:gpu: [drm] V3D: 35072kb BOs (30)
> [ 56.188325] vc4-drm soc:gpu: [drm] V3D shader:
> 124kb BOs (31)
> [ 56.188337] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5)
> [ 56.188345] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1)
> [ 56.188354] vc4-drm soc:gpu: [drm] total purged BO:
> 19540kb BOs (15)
> ...
>
> Except of these errors, X11 works as expected. Since I knew that this
> setup shouldn't throw these errors without CMA modifications, I
> bisected
> this to this commit:
>
> commit 47c07e46c86f310bed73b9c895155a49df3d5e71 (HEAD)
> Author: Maíra Canal <mcanal at igalia.com>
> Date: Thu Feb 2 08:19:43 2023 -0300
>
> drm/vc4: replace drm_gem_dma_object for drm_gem_object in
> vc4_exec_info
>
> After that I increased the CMA to 128 MB via Kernel cmdline and
> compared
> /proc/meminfo before and after the patch:
>
> Before
> CmaTotal: 131072 kB
> CmaFree: 20132 kB
>
> After
> CmaTotal: 131072 kB
> CmaFree: 5644 kB
>
> So my question: is this noticable CMA increase expected by this
> change?
>
>
> No, it shouldn't change anything. All it does is change the type we
> use to iterate over objects from the subclass to the base class in the
> command submission code. The resulting code should be entirely
> unchanged, if the compiler doesn't get confused at least and applies
> all the same optimizations.
>
> Can you please double-check that it's really this commit that makes
> the difference, and nothing else changed in the system?
Sorry, the fluctuation of meminfo wasn't a good indication so i used
"watch" on the output and it showed similiar values.
So i dropped the cma setting from cmdline in order to reproduce the
original issue. Unfortunately the error is reproducible only in 50%
percent of all cases. So I assume this is all caused by runtime (maybe
memory pressure) and a low CMA value.
Sorry for the noise
>
> Thanks, Sima
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
More information about the dri-devel
mailing list