Instances of lazy scheduling and timeslice donation in L4 implementations

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



Udo A. Steinberg wrote:
> On Wed, 25 Jan 2006 12:01:22 +1100 Sergio Ruocco (SR) wrote:
> 
> SR> Beware that Quantum and Timeslice are not the same thing. Quantum
> is the SR> amount of execution time after which the thread scheduler
> receives an SR> RPC. After the RPC the Quantum is re-initialised to
> the value of SR> thread's TimeSlice, but the thread scheduler is free
> to set it to any SR> value, including oo, independently from
> timeslice. SR> SR> So, to avoid confusion, let's keep Quantum outside
> of this discussion.
> 
> We are using conflicting terminology here. What I refer to as a time
> slice or scheduling context is a time quantum Q coupled with a
> priority P. A thread with such a time slice can run with priority P
> for Q units of time.

I was referring to the definitions of Timeslice and Quantum given in
these L4::Pistachio and N1 specifications [1]. From your description
seems that what you call quantum is what these specifications call
timeslice.


> I guess it is implementation-dependent. In our Fiasco kernel there is
> a strict distinction between time slices and execution contexts.
> During an IPC with lazy scheduling the kernel switches execution
> contexts but not time slices.
...nor priorities (or what follows is incorrect).

> This means that both A's priority and time quantum remain in effect -
> and thus B runs with A's priority and consumes A's time quantum
[2]
> until the time quantum is depleted and a new time slice is selected
> by the scheduler.


Here we enter in a tricky area. What is the difference from quantum and
timeslice from your perspective ?


> SR> In fact, as soon as a thread C of intermediate priority between A
> and B SR> is ready to run, it immediately preempts B, because B was
> running on A's SR> timeslice, not on A's priority.
> 
> Not in our kernel. An intermediate thread C can be woken up but it
> cannot preempt B as long as A's time slice hasn't run out.

...as long as A's time slice...or quantum ? To me they are not synonyms.
Moreover, writing 'timeslice' contradicts [2] above, unless Fiasco
conflates the notion of quantum and timeslice.

I keep asking because from the L4::Pistachio specification [1] they seem
to be quite different concepts. The end of a timeslice causes a
preemption. The end of a quantum causes an IPC to the thread scheduler.

> SR> What do mean with the "priority of A's time quantum" ??
> 
> In our model every time quantum is coupled with a priority. If it
> doesn't become clear from the description above I can elaborate some
> more.
> 
> - Udo

OK, what I understood from this discussion is that Fiasco follows a
specification that differs from [1], not only in substance, but also in
key terminology, and this can easily lead to confusion. I will read more
about Fiasco, and keep it consideration in the following discussion.

	Sergio


[1]
http://l4hq.org/docs/manuals/l4-x2-20051021.pdf
http://www.ertos.nicta.com.au/software/kenge/pistachio/latest/refman.pdf

-- 

--

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/9bccd3b4/attachment.vcf>


More information about the l4-hackers mailing list