Opened 13 years ago
Last modified 9 years ago
#427 new enhancement
Tickless/event-driven kernel
Reported by: | Martin Decky | Owned by: | Martin Decky |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | helenos/kernel/generic | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description (last modified by )
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:
Change History (6)
comment:1 by , 12 years ago
Description: | modified (diff) |
---|---|
Summary: | Tickless kernel → Tickless/event-driven kernel |
comment:3 by , 12 years ago
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.
comment:4 by , 11 years ago
Description: | modified (diff) |
---|
comment:5 by , 10 years ago
Milestone: | 0.5.1 → 0.5.2 |
---|
comment:6 by , 9 years ago
Milestone: | 0.6.1 |
---|
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 tasks *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 it 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.