gaf
User
 Platinum Osdever
| Posts: 153 |  | Karma: 10
|
Re: The next step - 2006/04/18 07:00
A decent scheduler doesn't switch tasks on every interrupt that occures, but only if the task's quantum has expired, or if a tasks with a higher privilege gets unblocked (if a IRQ occures). The task's quantum just states for how many clock ticks (or time-slices) the task may normally run. Interactive tasks are given a small quantum length, but get scheduled more often, while CPU bound tasks are assigned a longer quantum length to avoid task-switching overhead. It's thus perfectly possible that the schedule may return from a timer interrupt without having switched tasks, provided that the currently running task hasn't yet used its full quantum. A timer interrupt that doesn't initiate a task-switch is only unnecessary overhead, which is why the scheduler should seek to avoid it. This can be done by choosing a timer frequency that fits to the tasks' behaviour (20-50Hz) but, as the constitution of the tasks running on the system may change in time, it might by necessary to adapt the frequency at run-time. I myself are by the way planning to use single-shot timers that can be set to meet the tasks whole quantum length. With the local APIC this can be implemented in a very efficient way and it does avoid all unnecessary timer interrupts.
This is "preemptive" sheduling in enlish?
Yep, preemptive means that the kernel may interrupt a task, to schedule some other, at any time. The opposite is cooperative scheduling, where the kernel expects the tasks to return voluntarily after some time. This of course leads to some problems when a malicious tasks refuses to return, or some program just hangs. Nevertheless cooperative scheduling is still used today in some areas, as for example real-time systems, where tasks can be considered as safe and the overhead, that preemptive scheduling means, wouldn't be acceptable.
cheers, gaf
|