RT-Summit již tuto sobotu v Praze (diskuse)

[pc2005]

Jsem měl za to, že realtime planování umí i vanilla kernel.

[Pavel Píša]

Vanila umí "Preemptible Kernel (Low-Latency Desktop)", ale nikoliv Real-Time, kdy se ze spinlocků stanou mutexy. Klasický preempt nezvládá nezaručuje žádné omezení maximální latence - desítky milisekund jsou možné. Realtime "zaručuje" (vykazuje dlouhodobé maximální) latence na x86 s dobrým BIOSem do 50 usec, na ARMu do 150 usec.

[hajoucha]

Existuje nějaký referenční seznam hw, nebo jak člověk pozná "dobrý BIOS" ?

[Michal Kubeček]

Pro začátek by neměl podporovat věci jako SMI. Takže dnes už skoro žádný. :-(

[Peter Fodrek]

Hlavne to SMI musi mat dobre urobene.

videl so SMI, kde doslo k preruseniu velmi casto, ale len 10 mikrosekund, ale aj SMI (special;ista je Asustek), kde doslo k jednmu za nejaky cas, ale to trvalo 1500ms =1 500 000 mikrosekund, a tam to rozhodne nejde.

[fi]

Na druhou stranu vanilla jadro uz ma nohz_full, isolcpus a rcu_nocbs, takze se da vpodstate elimitovat beh jaderneho kodu na vybranych CPU jadrech a pak uz je jedno, jestli kernel pouziva mutexy a nebo spinlocky.

[Pavel Píša]

To sice ano, ale "RT" to bude jen za za podmínky, že nebude potřeba v daném vlákně žádná služba OS. S RT jádrem je možné mnoho znakových ovladačů (Comedi, ...) volat i v RT části, pokud odezva do nějakých třeba 200 usec stačí. Dokonce i na RPi je možné z RT části na 1 kHz volat přenosy do FPGA HW přes SPI a systém to zvládá (viz Lintarget RPi PMSM experiment). I když jak SPI subsystém tak síťový stack Linuxu obsahují mnoho kódu a konstrukcí, kde si myslím, že i na RT jádře hrozí inverze priorit. Pro takovýto projekt je pak ale stejně nejlepší použít Linux na FPGA, např. Xilinx Zynq (viz třeba můj příspěvek na LinuxDays.

[pc2005]

Aha tak dík za vysvětlení.