Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
kernel/sched: Clamp minimum timeslice when TICKLESS
When the kernel is TICKLESS, timeouts are set as needed, and drivers all have some minimum amount of time before which they can reliably schedule an interrupt. When this happens, drivers will kick the requested interrupt out by one tick. This means that it's not reliably possible to get a timeout set for "one tick in the future"[1]. And attempting to do that is dangerous anyway. If the driver will delay a one-tick interrupt, then code that repeatedly tries to schedule an imminent interrupt may end up in a state where it is constantly pushing the interrupt out into the future, and timer interrupts stop arriving! The timeout layer actually has protection against this case. Finally getting to the point: in recent changes, the timeslice layer lost its integration with the "imminent" test in the timeout code, so it's now able to run into this situation: very rapidly context switching code (or rapidly arriving interrupts) will have the effect of infinitely[2] delaying timeouts and stalling the whole timeout subsystem. Don't try to be fancy. Just clamp timeslice duration such that a slice is 2 ticks at minimum and we'll never hit the problem. Adjust the two tests that were explicitly requesting very short slice rates. [1] Of course, the tradeoff is that the tick rate can be 100x higher or more, so on balance tickless is a huge win. [2] Actually it only lasts until a 31 bit signed rollover in the HPET cycle count in practice. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
- Loading branch information