softhddevice-drm - "cma_alloc failed" - VDR verbraucht Speicher beim Verschieben von Schnittmarken

Quote from zillerbaer

Zu dem Zeitpunkt ist die aktuelle Aufnahme ja nicht geschlossen! Es wird ja eben diese abgespielt. Der Speicher wird von vdr freigegeben wenn die zu schneidende Aufnahme beendet wird.

Ich glaube, ich habe mich falsch ausgedrückt. Wenn der Speicher ausgeht, während die Aufnahme abgespielt und Marken gesetzt werden, ok... - das Problem habe ich aber hier gar nicht. Es geht mir erstmal nicht darum, dass der Speicher ausgehen kann, wenn man Maken setzt, die Aufnahme pausiert und dann wieder startet.

Meine Frage ist, warum der freie CMA Speicher VOR Wiedergabe der Aufnahme nicht NACH deren Beenden wieder in der gleichen Größe zur Verfügung steht?
Das Prozedere "Aufnahme abspielen, Schnittmarke verschieben, Aufnahme beenden, wieder Live-TV ansehen" verringert jedes Mal den CMA Speicher, bis er ausgeht.

Optimalerweise müsste es doch beispielhaft für den CMA so sein:

LiveTV: 150MB frei

Aufnahme abspielen, Pausieren, Schnittmarken verschieben, Schnittmarken anspringen etc....: geht runter bis auf 50MB frei (z.B.)

Wiedergabe stoppen, LiveTV fortsetzen: wieder 150MB frei

In Wirklichkeit sind es aber nur mehr 130MB und das nächste Mal 110MB etc...

Ist meine Theorie, dass ein als CMA allokierter Bereich beim Beenden der Wiedergabe nicht mehr freigegeben wird, denn so abwegig? Es geht mir nicht darum, was während der Wiedergabe mit dem Speicher passiert, sondern dass der CMA nach dem Beenden der Wiedergabe jedesmal schrumpft.

Quote from zillerbaer

Genau das wird gebraucht!

Bei den alten Allwinner SoCs war https://git.kernel.org/pub/scm/linux/…i-a20.dtsi#n175 notwendig, um den CMA im unteren Speicherbereich zu reservieren, damit die VE damit umgehen kann. Bei den neueren SoCs gibt es diese Einschränkung und somit auch die Reservierung über das dts nicht mehr, da läuft das über die Kernelconfig/-parameter und wird intern durch DMA zur Verfügung gestellt. LE reserviert z.B. 320MB über die Kernelconfig. Nur dem H3 wird als Kernel-Parameter noch "vmalloc=320M" mitgegeben, von dem ich nicht weiß, was es damit auf sich hat.

Quote from rell

Wenn der Speicher ausgeht, während die Aufnahme abgespielt und Marken gesetzt werden, ok... - das Problem habe ich aber hier gar nicht. Es geht mir erstmal nicht darum, dass der Speicher ausgehen kann, wenn man Maken setzt, die Aufnahme pausiert und dann wieder startet.

Darum geht es hier aber!

Quote from rell

Meine Frage ist, warum der freie CMA Speicher VOR Wiedergabe der Aufnahme nicht NACH deren Beenden wieder in der gleichen Größe zur Verfügung steht?

Die Beobachtung habe ich nicht gemacht.

CMA ist nicht das entscheidende. Wenn der low mem ausgeht kracht's.

Na dann reden wir wohl von 2 verschiedenen Beobachtungen und Problemen.

CMA ist am Ende schon entscheidend, denn wenn ffmpeg davon für av_frame_alloc nichts mehr bekommt - warum auch immer - krachts. lowmem hin oder her. Ich habe hier eh "nur" 1GB und wenn VDR nach dem Beenden der Wiedergabe wieder alles hergeben würde, was belegt wurde, hätte ich genauso viel wie vor Start der Wiedergabe und wäre glücklich. Aber so ist es halt nicht. Der freie Speicher wird jedesmal weniger.

Mir reichts für heute, ich denk da morgen wieder drüber nach. Schönen Dank bis hierhin.

Quote from JoeBar

Es kommen dann halt bei der Nächsten Aufnahme wieder die Meldungen im Log und das letzte Standbild flackert im Livebild.

Flackert bei dir das Standbild auch mit, wenn du nur eine Aufnahme bearbeitest? Bei mir kommt das schon beim Verlassen der Wiedergabe wenn ich die Aufnahme einmal pausiert habe und/oder eine Marke verschoben habe.

Da ist mal was zum lesen:

https://elinux.org/images/2/23/LinuxCMA-cewg43.pdf

Quote from zillerbaer

Da ist mal was zum lesen:

https://elinux.org/images/2/23/LinuxCMA-cewg43.pdf

Ok. D.h. wir haben die Situation Seite 6 mittlere Grafik. Der Speicherbereich für unser Multimedia liegt "dynamisch" im reservierten CMA-Bereich und kann auch von anderen Nutzern belegt werden, falls softhddevice das nicht tut. Wenn man davon keinen ausreichenden großen zusammenhängenden Bereich mehr frei hat, bekommt softhddevice ein Problem.

Wenn man über das dts für den Decoder entsprechend CMA reserviert, sollte der Speicher "theoretisch" von niemand anderem benutzt werden dürfen und wir wären auf Seite 6 untere Grafik.

Soweit so gut. Das erklärt, warum es krachen kann. Aber es erklärt nicht mein Problem mit dem ausgehenden Speicher aus Post #41, oder? Kann das noch jemand reproduzieren?

Ich glaube, ich werde dann jetzt doch mal CMA für die VPU über das dts reservieren und schauen, was das bewirkt.

Weiteres Problem:

Gestern hatte ich das erste Mal das Problem, dass im laufenden Betrieb ein altes Frame "mitgeflackert" ist. Beim Umschalten war das dann wieder weg. Ich weiß nicht, ob ich was besonderes gemacht habe und konnte das bisher nur beobachten, wenn ich eine Aufnahme bearbeitet habe und diese verlasse.

Kann das auch jemand bestätigen? JoeBar hast du da noch was rausgefunden?

Ich versuche in den nächsten Tagen mal hier weiterzukommen. Sonst läufts eigentlich ganz gut. Auch mit 2.5.4 jetzt.

Gruß

Andreas

Quote from rell

Gestern hatte ich das erste Mal das Problem, dass im laufenden Betrieb ein altes Frame "mitgeflackert" ist.

Das habe ich bei älteren Kerneln auch ab und an beobachtet. Mit dem aktuellem Kernel ist das nicht mehr aufgetreten.

Quote from rell

Ich glaube, ich werde dann jetzt doch mal CMA für die VPU über das dts reservieren und schauen, was das bewirkt.

Ich bin gespannt was da rauskommt.

Mit

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 4e89701df91f..26298a7f37fd 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -141,6 +141,19 @@
                interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
        };

+       reserved-memory {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               ranges;
+
+               linux,cma {
+                       compatible = "shared-dma-pool";
+                       no-map;
+                       size = <0x10000000>;
+                       linux,cma-default;
+               };
+       };
+
        timer {
                compatible = "arm,armv7-timer";
                interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,

habe ich jetzt folgendes:

andreas@orangepiplus:~$ cat /proc/meminfo
MemTotal:         734640 kB
MemFree:          304516 kB
MemAvailable:     399380 kB
......
CmaTotal:         262144 kB
CmaFree:          152228 kB

und

andreas@orangepiplus:~$ sudo dmesg | grep cedrus
[    1.958721] cedrus 1c0e000.video-codec: Device registered as /dev/video1
andreas@orangepiplus:~$ sudo dmesg | grep mem
[    0.000000] Reserved memory: created DMA memory pool at 0x6dfd7000, size 256 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000]   Normal   [mem 0x0000000040000000-0x000000006dfd6fff]
[    0.000000]   HighMem  [mem 0x000000006dfd7000-0x000000007dffffff]
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000006dfd6fff]
[    0.000000]   node   0: [mem 0x000000007dfd7000-0x000000007dffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007dffffff]
[    0.000000]   Normal zone: 1472 pages used for memmap
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 471472K/753664K available (7168K kernel code, 915K rwdata, 1996K rodata, 1024K init, 272K bss, 20048K reserved, 262144K cma-reserved, 152K highmem)

Wenn ich es richtig erkenne, wird der CMA reserviert und durch no-map nicht für das System zur Verfügung gestellt. Den Speicher direkt mit memory-region der VE zuzuweisen hat zu "[ 33.085565] cedrus 1c0e000.video-codec: failed to get scatterlist from DMA API" Fehlern geführt. Da habe ich noch keine Lösung.

Mal sehen, ob das schon ausgereicht hat, ich versuch das am Abend mal.

Gruß

Andreas