iMX5 nizky vykon HW

27.10.2021 17:07 | Přečteno: 1868× | linux

Dnes jsem objevil regresi v kernelu, zpusobujici nizky vykon procesoru s jadrem Cortex-A8 (SoC iMX515).

Problem se projevuje jako nizky vykon high level aplikacniho kodu (napr. Qt) a vysokymi latencemi v RT threadech (v radu stovek us).

Vsiml jsem si, ze benchmark (ramspeed -b2 -g1) mi ukazuje kolem 3GB/s do velikosti bloku 32kB, nad tuto velikost rychlost klesala k cca 250MB/s. Rikam si, ten procak ma mit L2 cache velikosti 256kB, takze bych mel videt zuby dva, jeden do 32kB a druhy do 256kB. Takze L2 cache nefunguje.

V roce 2007 byl do jadra zaveden commit 7092fc38ee770251aed361572bf6bed05fcf3ee2, ktery odstranuje podporu L2 cache z kernelu (z duvodu cistoty kodu). Bohuzel uz nikoho nenapadlo tu L2 cache nekde zapnout, takze na mem HW, kde se o to nepostara bootloader, je proste vypnuta. Revert tohoto patche resi vykonostni problem.

       

Komentáře

[🇹🇬]

hlavně žeto jako dobře dopadlo :O ;D

[vlastikroot]

Zitra udelam test s aktualnim kernelem (ted jedu LTS 4.19.x), beztak tam bude L2 cache vypnuta taky.

[xxxs]

a co to mas za masinku?

[vlastikroot]

TS-4800 v custom motherboardu, vyuzivam z toho 24bit RGB display, ethernet, UARTy a I2S (na zvuk). Bezi na tom Qt aplikace s QML GUI a WebSocket HTTP serverem pro dalkovy pristup.

[vlk]

celkom drahe na dnesnu dobu, co take olimexy, alebo rovno maliny s vinikajucou podporou, aj zmena dizajnu existujucich dosiek sa musi vratit,,, teda ked nemontujes menej nez 1 dosku za rok

[ajtacka]

Ako sa menia niektoré game engine a podpora hw, aj náročnejších a potreby a to posledných 80 rokov ak nerátame to predtým...

[vlastikroot]

V zarizeni, ktere to pohani, se cena takove desticky ztrati. Mnohem dulezitejsi je, je industry rated a jsou spolehlive. V dobe, ze ktere zarizeni pochazi, zrovna vysla RPi 1 a v porovnani s tim iMX to byla hracka.

[Salamek]

Zrovna maliny jsou celkem sracky pro industrialni pouziti, zkouseli jsme a bylo s tim tolik problemu (SD karty, napajeni) ale compute module 4 vypada celkem dobre a uvazuji ze bych to na zkousku vzal...

[BFU]

Ten patch je z roky 2007, iMX51 byla oznamena 2009 a treba u-boot zapina L2 cache na iMX51 od uplneho zacatku co byla iMX51 pridana (leden 2010). To vypada spis jako bug nejakeho custom bootloaderu, ktery spatne nastavil hardware.

Duvod proc se takove veci splachuji do bootloaderu je, ze kernel uz muze bezet v non-secure rezimu a nemusi byt schopny ten bit sam prepnout, protoze na to proste nema prava.

[vlastikroot]

Na tom TS-4800 se u-boot nikdy nepouzival - o first stage boot se stara proprietarni boot ROM v FPGA a second stage se cela vejde do MBR a jediny co dela je, ze skoci do linuxu. U-boot by byl zbytecny bloatware zpomalujici start. Na iMX6Q (Cortex-A9), kde mam u-boot, je zas L2 cache controller a ma normalne driver a zaznam v device-tree, takze tam se o to komplet stara linux (co nastavi u-boot je jedno).

[ja osobne]

./ramspeed -b2 -g1
RAMspeed (GENERIC) v2.6.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09

1Gb per pass mode

INTEGER & READING         1 Kb block: 66333.59 MB/s
INTEGER & READING         2 Kb block: 67501.21 MB/s
INTEGER & READING         4 Kb block: 65877.77 MB/s
INTEGER & READING         8 Kb block: 66708.61 MB/s
INTEGER & READING        16 Kb block: 66415.65 MB/s
INTEGER & READING        32 Kb block: 64504.50 MB/s
INTEGER & READING        64 Kb block: 52904.11 MB/s
INTEGER & READING       128 Kb block: 46680.37 MB/s
INTEGER & READING       256 Kb block: 50770.34 MB/s
INTEGER & READING       512 Kb block: 46111.05 MB/s
INTEGER & READING      1024 Kb block: 47230.66 MB/s
INTEGER & READING      2048 Kb block: 46806.53 MB/s
INTEGER & READING      4096 Kb block: 46216.24 MB/s
INTEGER & READING      8192 Kb block: 37196.17 MB/s
INTEGER & READING     16384 Kb block: 22572.78 MB/s
INTEGER & READING     32768 Kb block: 17838.91 MB/s

 ./ramsmp -b2 -g1
RAMspeed/SMP (GENERIC) v3.5.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09

1Gb per pass mode, 2 processes

INTEGER & READING         1 Kb block: 130048.06 MB/s
INTEGER & READING         2 Kb block: 129094.30 MB/s
INTEGER & READING         4 Kb block: 132765.60 MB/s
INTEGER & READING         8 Kb block: 131779.80 MB/s
INTEGER & READING        16 Kb block: 132827.19 MB/s
INTEGER & READING        32 Kb block: 129245.80 MB/s
INTEGER & READING        64 Kb block: 105206.92 MB/s
INTEGER & READING       128 Kb block: 103690.57 MB/s
INTEGER & READING       256 Kb block: 94602.80 MB/s
INTEGER & READING       512 Kb block: 89075.79 MB/s
INTEGER & READING      1024 Kb block: 88404.74 MB/s
INTEGER & READING      2048 Kb block: 85731.31 MB/s
INTEGER & READING      4096 Kb block: 79142.19 MB/s
INTEGER & READING      8192 Kb block: 40328.71 MB/s
INTEGER & READING     16384 Kb block: 28508.82 MB/s
INTEGER & READING     32768 Kb block: 26390.94 MB/s

[vlastikroot]

To asi nebude 32bit ARM co? Tohle je muj staricky pracovni Xeon E5-1620

RAMspeed (Linux) v2.6.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09

1Gb per pass mode

INTEGER & READING         1 Kb block: 36567.85 MB/s
INTEGER & READING         2 Kb block: 57293.73 MB/s
INTEGER & READING         4 Kb block: 57385.59 MB/s
INTEGER & READING         8 Kb block: 57244.86 MB/s
INTEGER & READING        16 Kb block: 57254.02 MB/s
INTEGER & READING        32 Kb block: 52163.91 MB/s
INTEGER & READING        64 Kb block: 37617.08 MB/s
INTEGER & READING       128 Kb block: 37563.12 MB/s
INTEGER & READING       256 Kb block: 34689.43 MB/s
INTEGER & READING       512 Kb block: 29190.46 MB/s
INTEGER & READING      1024 Kb block: 28709.67 MB/s
INTEGER & READING      2048 Kb block: 28650.69 MB/s
INTEGER & READING      4096 Kb block: 27997.75 MB/s
INTEGER & READING      8192 Kb block: 22062.13 MB/s
INTEGER & READING     16384 Kb block: 13156.50 MB/s
INTEGER & READING     32768 Kb block: 12628.54 MB/s

[ja osobne]

Linux vo virtuale na Xeon E-2136

[vlastikroot]

A tohle je ta iMX51 na 800MHz se zaplou L2 cache

RAMspeed (GENERIC) v2.6.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09

1Gb per pass mode

INTEGER & READING         1 Kb block: 3085.51 MB/s
INTEGER & READING         2 Kb block: 3091.51 MB/s
INTEGER & READING         4 Kb block: 3055.74 MB/s
INTEGER & READING         8 Kb block: 3075.60 MB/s
INTEGER & READING        16 Kb block: 3087.00 MB/s
INTEGER & READING        32 Kb block: 3079.39 MB/s
INTEGER & READING        64 Kb block: 1945.56 MB/s
INTEGER & READING       128 Kb block: 1771.25 MB/s
INTEGER & READING       256 Kb block: 783.45 MB/s
INTEGER & READING       512 Kb block: 320.12 MB/s
INTEGER & READING      1024 Kb block: 274.84 MB/s
INTEGER & READING      2048 Kb block: 267.41 MB/s
INTEGER & READING      4096 Kb block: 264.77 MB/s
INTEGER & READING      8192 Kb block: 264.05 MB/s
INTEGER & READING     16384 Kb block: 263.83 MB/s
INTEGER & READING     32768 Kb block: 263.84 MB/s

[David Heidelberg]

Budeš posílat patch s opravou do jádra?

[vlastikroot]

Ja zatim moc nevim, jak by takova oprava mela vypadat. Puvodnich par radek assembleru funguje, ale odstranili ho z duvodu, ze by nemel byt v generickem ARMv7 kodu. Takze predpokladam, ze by se mel dat nekam do mista specifickeho pro Cortex-A8, ale nevim presne kam. Navic to zrejme pro hromadu lidi resi u-boot a tim padem to pro ne neni problem.

[David Heidelberg]

Kdybychom se měli spoléhat na bootloader v době, kdy na většině telefonů s Androidem je mnohdy polofunkční fastboot (který je ještě locknutý, takže většinou nelze nahradit), to by ten Linux moc nefungoval. I když třeba před pár dny kluci co mají tablety Asus Transformery udělali velký pokrok s u-bootem.

Pokud nevíš kam s tím, napiš na linux-arm mailing list, buď někdo ten fix napíše nebo Ti alespoň řeknou kam s ním

[David Heidelberg]

oprava, spíš napiš těm, jejichž jméno vrátí

./scripts/get_maintainer.pl arch/arm/mm/proc-v7.S

[BFU]

Jak to bude fungovat na multi_v7 konfiguraci, bude tohle zapnute (takze kdyz kernel nastartuje nekde v NS rezimu nebo na ne-imx51, tak hrabne na ten bit a crashne, protoze nebude mit prava nebo to bude uplne jiny SoC) nebo to bude vypnute (takze multi_v7 bude stejne rozbita, i kdyz imx51 je armv7a) ?

[vlastikroot]

Souhlasim, podle me si linux zodpovida za stav procesoru, nemuze cekat ze ho dostane prednastaveny. Diky za tip.

[ajtacka]

Nejde nastaviť v bootloader, aby mal delay pri štarte 0 sekúnd(vteřin) a nastaviť to v ňom?

Čo keď jadro je ohybné ako nejaká dievka a treba ju viesť a nie sa hneď v nej hrabať...

Ak by mala byť oprava v jadre a nie v nejakom konfigurátore ako napríklad Anakonda z Red Hatu, tak by bolo treba zistiť ako sa zavádza L2 cache v jadre a urobiť implementáciu toho zapínania podľa architektúry, ak to bude potrebné.

Možné však aj je, že ten kód spôsoboval nejaký problém pod Linuxom alebo niekde inde a ide o nezdokumentovanú vlastnosť daného procesora špecifickú pre iný operačný systém ako je Linux a do Linuxu sa dostala bez schválenia právnikom(napríklad AMD mala/má s týmto veľký problém a sú na to potrebné špeciálne postupy, nehovoriac o iných grafikách/procesoroch kde napríklad pri nVidii je NDA s patentami zakazujúcimi zverejnenie a preto má problém s open source ovládačom, aj keď niekde pri nejakých nasadeniach sa vyžaduje, ale to je potom o niečom inom)...

Preto poradiť čo s tým by podľa mňa najlepšie vedel správca danej architektúry, ale možné je aj nesprávne riešenie problému ako teraz píšem...

[hmm]

Revert tohoto patche resi vykonostni problem

nejdriv jsi psal ze ho tam zavadi, tak ted nevim

[vlastikroot]

Commit z 2007 zavadi problem - odstranenim dulezitych radku. Revert, ktery si udelam na svym tree a navratim tim radky zpatky, problem vyresi. Nevim co je na tom k nevedeni

[hmm]

Myslim ze jsem napsal komentar Grety jinymi slovy Aneb jestli jsi na neco chteneho nezapomnel, ale do hlavy ti nevidim ale jestli ne, tak jsem te jenom nepochopil

[Mayhem]

Kde berete ten ramspeed??? To chci taky

[vlastikroot]

Ramspeed