Instances of lazy scheduling and timeslice donation in L4 implementations

Sergio Ruocco sruocco at
Tue Jan 24 14:55:27 CET 2006

Udo A. Steinberg wrote:
> On Tue, 24 Jan 2006 16:00:24 +1100 Sergio Ruocco (SR) wrote: SR> 
> Local experts believe that current L4 implementation(s) do not 
> conform SR> to specification, and Thread B will run only until the 
> next timertick.

> Your local experts are correct. In the L4 implementations that I know
>  of B will only run on A's time slice until a higher-priority thread 
> preempts B. I think this is what you meant by "next timer tick" (but 
> note that the next timer tick may wake up a lower-priority thread 
> which does not preempt B - therefore, preemption is what ultimately 
> breaks the donation, not the timer tick per se).

Local experts said 'timertick', but they were busy with other things, so
we may want to take a close look at the source and/or ask what they
meant exactly. I also found the answer 'timertick' a bit strange, as I
would expect donation to be terminated only by:

1) natural end of augmented timeslice
2) preemption by higher-priority thread

> Btw., this is the exact same issue as the IPC donation we discussed a
>  few days ago - the kernel does not maintain enough information to 
> restore the donation to B when A's time slice is selected by the 
> scheduler again. - Udo

On the one hand, remember that according to the specification the part
of timeslice that A donated to B via L4_ThreadSwitch() *adds* to B's
natural timeslice, so the kernel should have provision for this
donation-preserving behaviour. Again, a close look to the source seems

On the other hand, as Gernot pointed out, A's timeslice donation to B
when A IPCs to B is simply a *side* *effect* of lazy scheduling, a speed
optimisation that avoids to run the scheduler in the IPC path. Being the
timeslice donation a mere side-effect, actively carrying it over across
preemptions may probably not be the required behaviour.



ERTOS Researcher                                              Lecturer
National ICT Australia Ltd.              University of New South Wales

This email and any attachments are confidential. They may contain
legally privileged information or copyright material. You should not
read, copy, use or disclose them without authorisation.  If you are
not an intended recipient, please contact us at once by return email
and then delete both messages.  We do not accept liability in
connection with computer virus, data corruption, delay, interruption,
unauthorised access or unauthorised amendment.  This notice should not
be removed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sruocco.vcf
Type: text/x-vcard
Size: 114 bytes
Desc: not available
URL: <>

More information about the l4-hackers mailing list