Instances of lazy scheduling and timeslice donation in L4 implementations

[Udo A. Steinberg]

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.

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

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. 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
until the time quantum is depleted and a new time slice is selected by the
scheduler.

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20060125/732d3ab5/attachment-0001.asc>