tickless and timeslicing don't play well together #7193
Comments
|
Could the issue #7048 be caused by same root cause? |
|
@andyross will this be addressed for 1.13? |
|
The bug found by inspection will be fixed. Probably need some sort of longer term tracking on enhancing tickless (making it default where possible, expanding tests) and coming up with a better set of tests on timeslicing that look for fairness issues like this. |
|
FYI: @pizi-nordic |
|
Fix for the specific bug above is submitted. Probably should reprioritize rather than close this one, as the rework is if anything needed more now than before, given that we've added another #ifdef TICKLESS case. |
When adding a new runnable thread in tickless mode, we need to detect whether it will timeslice with the runnable thread and reset the timer, otherwise it won't get any CPU time until the next interrupt fires at some indeterminate time in the future. This fixes the specific bug discussed in zephyrproject-rtos#7193, but the broader problem of tickless and timeslicing interacting badly remains. The code as it exists needs some rework to avoid all the #ifdef mess. Note that the patch also moves _ready_thread() from a ksched.h inline to sched.c. Signed-off-by: Andy Ross <[email protected]>
|
Ugh, fixed correctly this time. No idea what happened earlier, presumably I rebased, but then forgot the "-a" on the commit? (And of course I put that comment in the bug and not the PR. Probably shouldn't be pushing until another coffee or three...) |
When adding a new runnable thread in tickless mode, we need to detect whether it will timeslice with the runnable thread and reset the timer, otherwise it won't get any CPU time until the next interrupt fires at some indeterminate time in the future. This fixes the specific bug discussed in #7193, but the broader problem of tickless and timeslicing interacting badly remains. The code as it exists needs some rework to avoid all the #ifdef mess. Note that the patch also moves _ready_thread() from a ksched.h inline to sched.c. Signed-off-by: Andy Ross <[email protected]>
When adding a new runnable thread in tickless mode, we need to detect whether it will timeslice with the running thread and reset the timer, otherwise it won't get any CPU time until the next interrupt fires at some indeterminate time in the future. This fixes the specific bug discussed in zephyrproject-rtos#7193, but the broader problem of tickless and timeslicing interacting badly remains. The code as it exists needs some rework to avoid all the #ifdef mess. Signed-off-by: Andy Ross <[email protected]>
When adding a new runnable thread in tickless mode, we need to detect whether it will timeslice with the running thread and reset the timer, otherwise it won't get any CPU time until the next interrupt fires at some indeterminate time in the future. This fixes the specific bug discussed in #7193, but the broader problem of tickless and timeslicing interacting badly remains. The code as it exists needs some rework to avoid all the #ifdef mess. Signed-off-by: Andy Ross <[email protected]>
|
Fixed as of the big timer rework. Tickless is default and all timeslicing tests pass with it enabled. Closing as I'm the one who opened it to begin with. |
Specific bug: wake up a thread (or create a new one) at the same priority as the currently running thread, both of which are at the same preemptible priority and in a situation where no other threads exist at that priority. In theory, the CPU timer should be adjusted to reflect the new situation and expire in one slicing tick. In practice, the timer is not adjusted and the new thread won't get any CPU until whenever the next interrupt fires, which could be a long time.
That issue was found via inspection as I stumpled over this code while working on the scheduler. The more general problem is that we have pretty poor test coverage for both timeslicing and tickless behaviors, this situation needs to be tested and handled, along with (probably) others.
The text was updated successfully, but these errors were encountered: