Huge latency on pselect
I have the following pre-condition on Linux (low latency kernel):
The problem I experience: There is another offending user space process which uses a lot of resources. When this one runs, it can cause huge latency spikes on my serial read thread. It can be 100 ms or more, even though serial data from the hardware arrives at 2.5 ms. I don't know too much about that other offending user space process, except that it is using the regular 'nice' scheduler and it spawns a lot of threads. My question:
At this point, I am happy for any hints/ideas, thanks! |
Do you happen to be pinning your process to CPU0 ?. If so pick another one - I like to stay away from the processors that the kernel has to run on in early boot as (to my simple mind) it's likely to reschedule there all the time. Might be nothing, but easy to implement as a test.
|
Quote:
In fact, I figured out what was the problem by tracing down scheduler events using ftrace: The tty driver relies on an unbound kernel worker to push data to the user via a workqueue. That kworker is scheduled with 'SCHED_OTHER'. This is kind of a strange situation, because I prioritized the tty IRQ and the receiving application both with SCHED_FIFO, but I have this SCHED_OTHER kworker in between, which is clearly the weakest chain in the link. There used to be a low_latency flag for tty, but it got removed because it was buggy apparently. Well, in any case I understood the problem and I am evaluation options to overcome this. |
All times are GMT -5. The time now is 06:10 PM. |