Instances of lazy scheduling and timeslice donation in L4 implementations

[Udo A. Steinberg]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20060124/6622abad/attachment-0001.asc>