vc4: Increased CMA usage after replace drm_gem_dma_object for drm_gem_object in vc4_exec_info

Fri Jul 5 15:19:52 UTC 2024

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?

Thanks, Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20240705/e9e93b62/attachment-0001.htm>