240 replies to this topic

[wimpie007]

ik kijk via cat /proc/pid/status naar 't geheugengebruik van enigma2.

Bij een 'normale' film word 't geheugen netjes vrijgegeven na het stoppen van de film. Bij de problematische films niet. Never. de box hangt zichzelf liever op dan ram vrij te geven.

en 15 meg meer of minder vrij zal 't verschil niet maken als bij sommige films je op 5 minuten die 15 meg al hebt opgesoupeerd:)

een valgrind op de vu is voor mij in elk geval te hoog gegrepen jammer genoeg.

In elk geval is het probleem niet te te linken aan openpli zelf. VIX bv. zit met hetzelfde probleem (maar dat was te verwachten)

 

[Erik Slagter]

Vs. 

root@dm8000:~# cat /proc/meminfo 
MemTotal:       151884 kB 

which makes 9.93% 

[littlesat]

Is dat niet een beetje meer dan de 112 MB en de 128 MB die ik had aangegeven ivm de "gemeenschappelijke" OSD framebuffer?

[Erik Slagter]

@wimpie, mocht valgrind beschikbaar komen, dan zal ik je wel een even een stappenplan geven om valgrind uit te voeren (en dan de output hier neerzetten), dan komen we al een heel eind.

 

Op mijn dm7000 had enigma altijd vaste prik 98% van het geheugen in gebruik en zo draaide hij maandenlang. Hier op dm8000 heeft hij 142% in gebruik zie ik net Zo zie je maar weer hoe weinig zo'n geisoleerd getal zegt.

[Erik Slagter]

Is dat niet een beetje meer dan de 112 MB en de 128 MB die ik had aangegeven ivm de "gemeenschappelijke" OSD framebuffer?

Het geheugen voor de hardware (osd, framebuffer, decoder en demuxer buffers enz.) zie je niet onder linux.

[MiLo]

Ik zie dat valgrind wel wordt aangeboden via OE, het zit alleen niet in de feed bij ons. Misschien dat pieterg of MiLo die

Blijkbaar geen valgrind voor MIPS...

$ bitbake valgrind
..
ERROR: valgrind was skipped: incompatible with host mipsel-oe-linux (not in COMPATIBLE_HOST)

[Zuppelan]

Ook libc (malloc enz.) heeft een heel eigen systeem van memory management waarbij, om fragmentatie te voorkomen, geheugen zelden direct teruggegegeven wordt aan de kernel.

 

Juist veel te vaak   In mijn beroep is dat juist één van de meest voorkomende oorzaken van prestatieproblemen: Geheugen dat continu van de kernel gealloceerd wordt en weer vrijgegeven wordt houdt een parallelle applicatie ernstig. Het geheugenmanagement van de kernel is niet schaalbaar naar grote hoeveelheden threads en bovendien moet de kernel alle geheugen dat gealloceerd wordt nog wissen ook, zodat een free-aanroep zomaar even alle caches leeg kan gooien. Speciaal als je tientallen servers aan 1 probleem hebt rekenen dan komt het als je dit niet aanpakt zo voor dat 90% van de processorkracht verspild worden aan spinnen in lusjes.

 

MMAX_MALLOC_MAX_ en MALLOC_TRIM_THRESHOLD_ zijn omgevingsvariabelen waarmee je de libc op dit gebied kunt tunen. Voor supercomputers zet ik de MMAX_MALLOC_MAX_ altijd op nul en de MALLOC_TRIM_THRESHOLD_ op een halve gigabyte, maar dan nog kom ik met regelmaat evil geniussen tegen die programma's schrijven die herhaaldelijk meerdere gigabytes alloceren en vrijgeven.

 

Ook voor Enigma zou geheugen teruggegeven moeten worden, maar wat bij Enigma een grote rol kan spelen is garbage collection van de Python-interpreter. C-code alloceert geheugen, Python alloceert wat geheugen in hetzelfde heapblok, C-code geeft het weer vrij... ja, dan is er in dat blok toch nog geheugen in gebruik, totdat de garbage collection ooit eens aan de slag gaat.

[Zuppelan]

Wat je zou kunnen doen om geheugenlekken zonder Valgrind op te sporen is malloc om te leiden:

 

http://www.gnu.org/s...for-Malloc.html

 

Aan het begin van elk geheugenblok sla je het return-adres van de stack op en je linkt ze in een dubbel gelinkte lijst. Zodra het programma eindigt loopt je de gelinkte lijst af en druk je het adres af van alle blokken die nog in de lijst staan. Je hebt dan de programma-adressen van plaatsen waar geheugen gealloceerd is dat nooit vrijgegeven is.

[Erik Slagter]

Ga jij dat even aanpassen in enigma?

[Erik Slagter]

Ik zie dat valgrind wel wordt aangeboden via OE, het zit alleen niet in de feed bij ons. Misschien dat pieterg of MiLo die

Blijkbaar geen valgrind voor MIPS...

$ bitbake valgrind
..
ERROR: valgrind was skipped: incompatible with host mipsel-oe-linux (not in COMPATIBLE_HOST)

Jammer. Volgens deze pagina support valgrind wel mips/linux.

[wieckbud1]

ik heb de laatste updates gedaan op mijn Vuo+duo en nu al enkele mkv bestanden afgespeeld. Het probleem van de tandwieltjes heb ik niet meer gehad.

Wel dat het beeld begint te haperen. Film een 20tal seconden op pauze gezet en daarna speelt hij het weer goed af.

Misschien dat iemand iets aan deze informatie heeft, vandaar dat ik het even aangeef

[MiLo]

Ook voor Enigma zou geheugen teruggegeven moeten worden, maar wat bij Enigma een grote rol kan spelen is garbage collection van de Python-interpreter. C-code alloceert geheugen, Python alloceert wat geheugen in hetzelfde heapblok, C-code geeft het weer vrij... ja, dan is er in dat blok toch nog geheugen in gebruik, totdat de garbage collection ooit eens aan de slag gaat.

Python is geen Java.

Python gebruikt reference counting als primaire strategie. Dus geheugen wordt vrijgegeven zodra het de scope verlaat. Net als de C++ code dus eigenlijk. Python gebruikt wel een garbage collector om cycles te detecteren (en doorbreken). In je python code dus zoveel mogelijk voorkomen dat je cycles maakt, dat scheelt behoorlijk.

[Roymar]

ik ben voor de gein eens terug gegaan naar de 2.1 image met oude kernel en ik moet zeggen, de MKV's afspelen in die image geeft geen enkele problemen(meerdere geprobeerd),

het enigste wat me tegen houd is dat de plugin feeds voor 2.1 niet meer bestaan en als ik de 4.0 feeds er in zet zie ik niet alle plugins en mis ik dingen als epg import en subtitleplayer.

dus toch maar weer terug naar 4.0 en een externe mediaplayer gebruiken, wat ik wel erg jammer vind

[Erik Slagter]

Bepaalde niet al te grote plugins kunnen we er natuurlijk wel instoppen...

[Roymar]

Dat zou natuurlijk erg mooi zijn, want met de standaard image zit er niks in, dus ook geen softcams. zelfs met de feed van openpli 4 kwam oscam en CCcam ook niet beschikbaar alleen hypercam, mgcamd en scam

[Erik Slagter]

CCcam heb ik er al in zitten. De rest vind ik niet zo nodig.

[korsan]

Vandaag met VTI de laatste kernel 3.9.6 getest op de Vuduo en het probleem van toename van het geheugen bij het afspelen van sommige mkv/mpv lijkt nu opgelost te zijn.

Het geheugengebruik neemt niet meer toe, waardoor de box na enige tijd niet meer vastloopt!

Hoop dat dit ook opgelost wordt in Openpli wanneer de nieuwe drivers ingeburgerd zijjn..

[Erik Slagter]

Hebben we het dan over de duo of de duo2? Want de voor de duo was toch geen nieuwe kernel? En met de duo2 heb ik zelf nooit dit soort problemen eigenlijk.

[40H3X]

* Update drivers
- 20140715(duo, solo, duo2, solo2, solose)
- 20140716(uno, ultimo)
- Support SoloSE
- Switch to Kernel 3.13.5(solo2, duo2, solose)
- Switch to Kernel 3.9.6(duo, solo, uno, ultimo)
- Fix sound drop in radio channel
- Improve PIP(solo2, duo2, solose, Needs E2 update)
- Allocate more memory to linux(duo2)
- Improve media playback

[Zuppelan]

Toch wel. De eerste generatie ontvangers had 3.1.1, is nu 3.9.6. De tweede generatie had 3.3.8, is nu 3.13.5.