Linux and WorkQueues

[nicolaerosia]

Hello,

After surfing through the code I noticed that every DevObj's execute function is ran by the HRTWorkQueue. Since all sensors inherit DevObj, and they interact with low speed busses like I2C, SPI, and all of these syscalls sleep, the latency and jitter will be high and unpredictable. In my opinion, on Linux, every sensor should have its own thread and the Linux scheduler should handle the scheduling. For more info on RT Scheduling, check [0] [1] [2]. As it is today, we're not even taking advantage of SMP (with the exception of some threads started by px4_task_spawn_cmd).

Let me know if I'm missing something, thanks.

[0] https://www.spinics.net/lists/linux-rt-users/msg16805.html [1] https://www.spinics.net/lists/linux-rt-users/msg16808.html [2] https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/cyclic

[mcharleb]

@nicolaerosia In Linux if PX4 is run as root, the thread running the work queue will run as a realtime thread and so should preempt other SCHED_OTHER threads. Its true that all the buses are managed by one work queue and one proposed enhancement is to have a workqueue per bus.

[nicolaerosia]

@mcharleb yes, but all I/O is done on that Work Queue, hence all sensors I/O are serialized, e.g. read gyro, then read acc, then read mag, then read baro, etc. I would go for a thread per sensor

[dagar]

This should be resolved in the updated drivers PX4 side with a thread per bus.