Instances of lazy scheduling and timeslice donation in L4 implementations

[Udo A. Steinberg]

On Tue, 24 Jan 2006 20:59:21 +0100 Espen Skoglund (ES) wrote:

ES> This can be argued about.  If high-priority thread B is in no way
ES> penalized by running on a dontated lower priority timeslice for a
ES> while, then it is not necessarily a bad thing.

I consider B to be penalized if it can be preempted by a thread with a lower
priority than that of B.

ES> Once the timeslice
ES> expires or is preempted, and if thread B is now eligible to be
ES> scheduled then it will continue to run on its own timeslice with its
ES> own priority.

That way B is not penalized (according to the definition above), but there
is no clean accounting. Clearly B is handling a request on behalf of A -
and initially the consumed time is accounted to A. After a preemption
B continues to run with its own priority and consumes its own time. Thus,
some or all of the time required to handle the request will be accounted to
the client, some or none to the server. Also you can incur an unnecessary
preemption of B (while it's running on A's priority) if a thread between
A's and B's priority is released (admittedly, this is not a common case).

Imho you want to either account the consumed time completely to the client
or completely to the server.

ES> Now for how things are implemented in Pistachio:
ES> 
ES>   o If send phase finished and there is *no receive phase* the kernel
ES>     will donate the timeslice to the destination thread *if* the
ES>     destination runs on a higher priority.  If destination does not
ES>     run on a higher priority the current thread will contine executing
ES>     its own timeslice.

What is the motivation for donating to the destination thread of a send-only
IPC if the destination has a higher priority? A pure send operation does
not establish a dependency between both parties, i.e. the caller does not
wait for the callee to reply.

ES>   o If receive partner is not ready and there was a send phase
ES>     (remember send and receive partner may be different) we block and
ES>     donate the timeslice to the send partner.

The receive partner is the party to which you send or from which you
receive? This is a bit confusing because during request and reply the
sender and receiver roles of both parties switch.

			- 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/20060124/d6982fe2/attachment-0001.asc>