Instances of lazy scheduling and timeslice donation in L4 implementations

Sergio Ruocco sruocco at cse.unsw.edu.au
Wed Jan 25 02:01:22 CET 2006



Udo A. Steinberg wrote:

> 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.

Beware that Quantum and Timeslice are not the same thing. Quantum is the
amount of execution time after which the thread scheduler receives an
RPC. After the RPC the Quantum is re-initialised to the value of
thread's TimeSlice, but the thread scheduler is free to set it to any
value, including oo, independently from timeslice.

So, to avoid confusion, let's keep Quantum outside of this discussion.


> 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.

No. I think that with IPC Lazy Scheduling B does not get a priority
boost, but only to run for the remaining part of A timeslice. This is
not the same as B running with A priority.

In fact, as soon as a thread C of intermediate priority between A and B
is ready to run, it immediately preempts B, because B was running on A's
timeslice, not on A's priority.


> 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

Again, I think that priority is really not involved here.

> 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

What do mean with the "priority of A's time quantum" ??

> the duration of the IPC.
> 
> - Udo

If you mean to run B on A's scheduling parameters for the entire
duration of the RPC call, I think that this would go waaay past the
intentions of original IPC Lazy Scheduling, and seriously confuse
scheduling.

	Sergio


-- 

--

http://www.cse.unsw.edu.au/~sruocco/
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: 107 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20060125/4932723b/attachment-0001.vcf>


More information about the l4-hackers mailing list