Skip to content
Browse files

kernel/sched: Interpret zero timeslice time correctly

The scheduler API has always allowed setting a zero slice size as a
way to disable timeslicing.  But the workaround introduced for
CONFIG_SWAP_NONATOMIC forgot that convention, and was calling
reset_time_slice() with that zero value (i.e. requesting an immediate
interrupt) in circumstances where z_swap() had been interrupted

In practice, this never happened.  And if it did, it was a single
spurious no-op interrupt that no one cared about.  Until it did,

Now that ticks on nRF devices are at full 32 kHz speed, we can get
into a situation where the rapidly triggering timeslice interrupts are
interrupting z_swap() calls, and the process feeds back on itself and
becomes self-sustaining.

Put that test into the time slice code itself to prevent this kind of
mistake in the future.

Signed-off-by: Andy Ross <>
  • Loading branch information...
andyross authored and nashif committed Jun 16, 2019
1 parent 17051e4 commit ed7d86310f635e89e721b4e70f534ea81d6b62b0
Showing with 4 additions and 3 deletions.
  1. +4 −3 kernel/sched.c
@@ -255,9 +255,10 @@ static void reset_time_slice(void)
* slice count, as we'll see those "expired" ticks arrive in a
* FUTURE z_time_slice() call.
_current_cpu->slice_ticks = slice_time + z_clock_elapsed();

z_set_timeout_expiry(slice_time, false);
if (slice_time != 0) {
_current_cpu->slice_ticks = slice_time + z_clock_elapsed();
z_set_timeout_expiry(slice_time, false);

void k_sched_time_slice_set(s32_t slice, int prio)

0 comments on commit ed7d863

Please sign in to comment.
You can’t perform that action at this time.