Changes between Initial Version and Version 1 of Ticket #427, comment 2


Ignore:
Timestamp:
2013-05-28T11:35:35Z (11 years ago)
Author:
Jiri Svoboda

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #427, comment 2

    initial v1  
    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.
     1The !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.
    22
    33On 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.
     4
     5There 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.
     6
     7There 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.