Reputation: 81
In experimenting with scheduling a high speed thread, I've noticed that sometimes there are large periods (multiple ms) that the thread is not scheduled. I was wondering what might be able to do this to the scheduler in the configuration I am using.
I confirmed that only things like worker, timer, etc are on CPU1. Everything else is on CPU0.
My thread is SCHED_DEADLINE (The only one scheduled like that) with a period of 300us. I use schedules_yield() to release the thread long before the reservation is up (Just a test loop) so I'm sure it's not over running.
What I get is an almost perfect 3333Hz output (Via an o-scope) which gets blocked every now and then for upward of 15ms at a time. I've looked at interrupts (Which aren't incrementing on that CPU except for the timer), I've disabled NMI interrupts and so on with no luck in finding what the interfering process is. I don't believe I fully understand what can take priority and cause the scheduler to skip periods so I'm hoping someone might have an idea?
I thought it might be disk IO, but that doesn't seem to align with the gaps (Sometimes it does...). VGA/console use seems to make it worse, but even when not being used the gaps still appear.
And yes, before you ask.... This is just an experiment to see if this can be done reliably. My actual code runs on QNX which is rock-steady at this rate on the same hardware. I'm experimenting to see if that can be ported to Debian with PREEMPT_RT.
Thanks!
Upvotes: 1
Views: 594
Reputation: 10947
SCHED_DEADLINE
tasks have higher priority over all the other user-level tasks with different priorities (i.e. SCHED_RR
, SCHED_FIFO
, SCHED_OTHER
).
Note that since kernel 4.16, overruning can be checked by using the SCHED_FLAG_DL_OVERRUN
and a user-level handler on the SIGXCPU
signal (see here).
If you need to check what the CPU is doing, ftrace is probably the best approach.
Upvotes: 0