Instances of lazy scheduling and timeslice donation in L4 implementations

[Espen Skoglund]

[Udo A Steinberg]
> 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.

This can be argued about.  If high-priority thread B is in no way
penalized by running on a dontated lower priority timeslice for a
while, then it is not necessarily a bad thing.  Once the timeslice
expires or is preempted, and if thread B is now eligible to be
scheduled then it will continue to run on its own timeslice with its
own priority.

Now for how things are implemented in Pistachio:

  o If send phase finished and there is *no receive phase* the kernel
    will donate the timeslice to the destination thread *if* the
    destination runs on a higher priority.  If destination does not
    run on a higher priority the current thread will contine executing
    its own timeslice.

  o If receive partner is not ready and there was a send phase
    (remember send and receive partner may be different) we block and
    donate the timeslice to the send partner.

  o When the receive IPC copy operation occurs we switch to the
    receive partner (the IPC copy operation always happens in the
    context of the sender) if it has a higher priority than the send
    partner.  Otherwise we switch to the send partner.  Again,
    timeslice donation occurs.

  o After the receive phase has finished the scheduling is decided
    upon by the party doing the last send operation (see the two first
    bullets above).

Hope this clears up a few things regarding the Pistachio
implementation.  Note that this is pretty much just from the top of my
head, though.  There might be some slight differences in the actual
implementation.   Also note that other things such as delayed
preemtion also complicate these scheduling decisions.

	eSk