On Wed, 25 Jan 2006 00:55:27 +1100 Sergio Ruocco (SR) wrote:
SR> Local experts said 'timertick', but they were busy with other things, so SR> we may want to take a close look at the source and/or ask what they SR> meant exactly. I also found the answer 'timertick' a bit strange, as I SR> would expect donation to be terminated only by: SR> SR> 1) natural end of augmented timeslice SR> 2) preemption by higher-priority thread
Correct.
SR> On the one hand, remember that according to the specification the part SR> of timeslice that A donated to B via L4_ThreadSwitch() *adds* to B's SR> natural timeslice, so the kernel should have provision for this SR> donation-preserving behaviour. Again, a close look to the source seems SR> necessary.
The specification is not very precise in defining the behavior. Imagine A having a high priority and B having a low one. Simply adding A's time quantum to that of B means you downgrade A's high-priority time to the low priority of B, which has different semantics than attaching A's scheduling parameters (e.g., time quantum coupled with priority) to B. In the latter case B can run with A's high priority until A's time quantum is depleted.
SR> On the other hand, as Gernot pointed out, A's timeslice donation to B SR> when A IPCs to B is simply a *side* *effect* of lazy scheduling, a speed SR> optimisation that avoids to run the scheduler in the IPC path.
I think Jochen's idea of lazy scheduling was primarily focused on not having to manipulate the ready queue during IPC. What Gernot probably meant is that switching from A to B without also switching to B's scheduling parameters means you have to load less state from B, which improves performance.
SR> Being the SR> timeslice donation a mere side-effect, actively carrying it over across SR> preemptions may probably not be the required behaviour.
The "side effect" of L4 IPC only implements desired donation behavior in the case when a high-priority thread A calls a low-priority thread B. In that case B will be boosted to A's priority and priority inversion is avoided. However, if A has the lower priority and calls a high-priority thread B, then A effectively drags B down to its priority level, which is imho not desired. In that case the IPC implementation should switch to B's scheduling parameters or boost the priority of A's time quantum to the priority of B for the duration of the IPC.
- Udo