Tickless/event-driven kernel

[Martin Decky]

The kernels of many operating systems have already switched or are planning to switch to tickless operation (i.e. avoiding strictly periodic timer interrupts and scheduling timers on-demand).

The benefits are lower overhead, better power-saving possibilities (even without any specific power management features) and a more natural design of the timers without a fixed timer period. The most significant drawback is naturally more complex timer bookkeeping, but as empirical evidence shows it is manageable.

Clarification: The term "tickless" is usually understood as a means to avoid periodic timer interrupts in idle states. However, an "event-driven" kernel design can actually go even further and avoid all periodic timer interrupts. See the following references in the context of Linux:

• ​http://linuxplumbersconf.org/ocw/proposals/103
• ​http://events.linuxfoundation.org/sites/events/files/eeus13_mckenney.pdf
• ​http://events.linuxfoundation.org/sites/events/files/slides/BareMetalLPC.2013.09.22a_0.pdf

[Jiri Svoboda]

The McKenney proposal still requires one of the CPUs to maintain strictly periodic scheduling interrupts. This is actually not needed either. If there are fewer tasks than there are CPUs, we can just leave everyone runnning. As soon as there is a new task *and* the scheduler determines there will be a need to switch tasks on some CPU at a specified point in time, it can schedule a timer on that CPU.

On the other hand I would be careful putting all switching into the hands of a single CPU. If that CPU has a problem, the entire system could effectively become non-preemptive.

There is much more to an event-driven kernel or *system*. First thing, even when there are tasks to run and switch, you should only schedule timers for when the next event (e.g. switch) happens. Say if you have a kernel ticking at 100 Hz, but the current task's time slice will expire in 3 ticks, there is no need to run timer interrupt 3 times just to find out there is not a switch happening twice.

There are many possible sources of periodic wakeups in the system, not just kernel (drivers, applications). These wakeups can be eliminated or made less frequent. Their impact can be also lowered by timer coalescing (this requires the timer API to allow for the timer to fire in a time interval, as opposed to a precisely specified time), etc, etc.

[Martin Decky]

Replying to svoboda:

On the other hand I would be careful putting all switching into the hands of a single CPU. If that CPU has a problem, the entire system could effectively become non-preemptive.

That's certainly true, although I doubt the SPARTAN kernel can even survive running on a system with a failing CPU currently.

A naive, but working solution to this problem in the event-driven system is to have a periodic watchdog timer interrupt delivered to all CPUs. With a period of say one minute or even more it won't hurt anybody (not even in the hard real-time domain if implemented correctly), but it can salvage a dying system.