kernel: sched: default TIMESLICE_SIZE

[moonlight83340]

Subject: Regression after commit e337b7b (CONFIG_TIMESLICE_SIZE change)

Hello,

I am facing a regression after commit [e337b7b65d](e337b7b) which changed the default value of CONFIG_TIMESLICE_SIZE from 0 to 20.

My setup:

• I have a bootloader that normally runs correctly at first boot.
• I can also reload the bootloader from ITCM by triggering it from a register.
• Before this commit, Zephyr would boot normally in both cases.

After this commit:

• When I reload from ITCM, Zephyr does not finish booting anymore (it "hangs").
• If I explicitly set CONFIG_TIMESLICE_SIZE=0 in my prj.conf, the problem disappears.

I am not fully familiar with how timeslicing works in Zephyr, so I am wondering if this behavior is expected or if it reveals a bug in the scheduler.

Thanks for your help!

[yashi]

It doesn’t appear to be a regression in the Zephyr project itself, but rather something specific to how your application is set up.

To better understand the behavior, the following documentation may be helpful:

• Scheduling
• CONFIG_TIMESLICE_SIZE

One way to experiment is to create two cooperative threads at the same priority and see how they behave with different CONFIG_TIMESLICE_SIZE values. This can give you a clearer picture of how timeslicing affects scheduling.

My initial thought is that you might have several threads with the same priority. With CONFIG_TIMESLICE_SIZE=0, Zephyr lets a thread run as long as it needs, but once you set a non-zero value, the scheduler will preempt and switch tasks. That could explain why your original thread doesn’t seem to resume as expected.

It may help to review your thread priorities and confirm whether timeslicing is the right fit for your use case.