Instances of lazy scheduling and timeslice donation in L4 implementations

Gernot Heiser gernot at
Sun Jan 22 12:02:43 CET 2006

>>>>> On Fri, 20 Jan 2006 14:04:03 +0100, "Udo A. Steinberg" <us15 at> said:
UAS> [...]
UAS> Also note that time-slice donation on L4 typically does not extend across
UAS> preemptions. A client that performs an RPC to a server donates its time
UAS> quantum and priority to the server - this is achieved by switching only the
UAS> execution context during the IPC and leaving the scheduling parameters
UAS> of the client "in place". However, if the RPC is preempted by a higher-
UAS> priority thread and is later resumed, the server will continue executing
UAS> using its own time and priority instead of using the client's time and
UAS> priority.

UAS> To my knowledge no existing L4 implementation correctly resumes the original
UAS> donation after a preemption. A solution has been described in [1], but we at
UAS> TUD have not implemented it yet.

You imply that donation across preemptions is the "correct"
behaviour. This is at least debated. In fact, the original motivation
is not at all to donate a time slice, but to do lazy scheduling,
i.e. do not invoke the scheduler if it isn't required(*). This is not
proper time-slice donation (even though my old Inside-L4 document
might be seen to imply that it is).


(*) scheduler invocation isn't required because (assuming prios are
handled correctly, which in many implementations aren't) dispatching
the receiver is the correct (and in cases of ambiguity, the most
efficient) thing to do. The drawback is that it makes CPU time
accounting inaccurate.

More information about the l4-hackers mailing list