Raspberry Pi interrupt delay v0.2
2019-09-26T13:49:30+02:00
2019-09-27T18:08:43+02:00
2022-07-19T00:30:14+02:00
@sanya
Sziasztok.

Ez igazából a Raspberry Pi interrupt delay probléma topicnak lenne a folytatása.
Szóval visszatérek a legújabb fejleményekkel, hátha érdekel valakit.
Írtam egy egyszerű kernel drivert a raspberry-re ami egy megszakítást telepít link egy gpio-ra, majd az ISR-ben egy másik gpio szintjét változtatom (toggle) hogy egy logic analyzer-rel láthassam mennyi idő szükséges az ISR meghívásra. Ugye érthető? :)
Az idő persze javult, az eredeti 50-70us-hoz képest, most 5-10us lett. Mondom meg kéne próbálni mi lesz ha egy stress-test is fut a gépen, így biztos sokkal lassúbb lesz. Hát legyen, elindítottam ezt: 

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run
Nézem htop mit mond: 100% mind a 4 CPU. Szuper. Elindítom a mérést (Saleae Pro 8-at használok) és amikor nézem az erdményeket ledöbbenek: átlagosan 1.8us!
Megismétlem stressteszt nélkül, megint 5-10us között van, mégegyszer 100% CPU load alatt: megint 1.6-1.9us. Szóval akárhányszor teszem, mindig ugyanazt az eredményt kapom.
Teljesen biztos az én tudatlanságom az oka annak, hogy nem értem ezt a viselkedést, mivel a Linux kernel nem az én erősségem.
Lehetséges az, hogy nagy terhelés alatt a CPU jobban kihasználódik, mint amikor az 0% körül mozog, vagy nem is tudom... Ha hülyeséget írtam, bocsi… :) Még annyit, hogy a /proc/interrupts azt mondja, hogy mindig ugyanaz a a cpu (csak a CPU0 a másik három soha) kezeli ezt az interruptot. ha ennek egyáltalán van valami haszna itt.

Szóval a kérdésem az, hogy hogyan lehetséges az, hogy 100% CPU load mellett kisebb a válaszidő mint amikor 0% körül van?

Hátha egy Linux guru erre téved és elmondja nekünk mik mennek itt végbe…
Köszönöm!
Mutasd a teljes hozzászólást!
Szerintem a CPU frekvenciához lesz köze. Amikor IDLE van, akkor letekeri a rendszer, hogy spóroljon a fogyasztással. Amikor terheled, akkor meg feltekeri. Mivel magasabb az órajel, így gyorsabban lefut az interrupt is.
Mutasd a teljes hozzászólást!

  • Nahát, erről nem is tudtam.

    CPU load 0%:
    pi@raspberrypi:~ $ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
    600000

    CPU load 100%:
    pi@raspberrypi:~ $ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
    1400000


    Köszi
    Mutasd a teljes hozzászólást!
  • Abból hogy az órajel cca kétszeresére nőtt és a kiszolgálási idő kb. felére csökkent, nekem az jön le, hogy a megszakítás úgy viselkedik mint egy realtime os-ben, avagy nem megy át a kernel ütemezőjén. Amúgy ennek szerintem így is kell lennie.
    Hmm, viszont ebben az esetben még a 2us kiszolgálási idő is elég soknak tűnik nekem…
    Mutasd a teljes hozzászólást!
  • Ez Where is hardware interrupt latency documented for the ARMv8 Cortex-A53? valószínűleg megadja a választ.

    I'm not aware that such a measurement exists for the Cortex-A cores; the best case will never happen for any real software so it's not really something which really worth measuring, and as per my first answer the realistic and worst case is totally dependent on the memory system performance which is not under control of the CPU design.
    ...
    For an A-profile core you'll probably find that the latency is dominated by memory system effects caused by the need to fetch instructions and data from main memory to actually run the handler. The costs involved will include both cache fetches and page-table walks to translate addresses.
    ...
    It's worth noting that the Cortex-A profile cores are not designed to give really fast / consistent interrupt latency response
    Mutasd a teljes hozzászólást!
  • Hát tényleg meg...
    Mondjuk, hogy ha az idle CPU órát nézem, akkor 600 ciklusidő jut 1us-ra és akkor az 5us (ami 3000 ciklus) egy interrupt kiszolgálásra így már reálisnak tűnik.

    Köszi!
    Mutasd a teljes hozzászólást!
abcd