Instances of lazy scheduling and timeslice donation in L4 implementations

[Udo A. Steinberg]

On Wed, 25 Jan 2006 11:09:09 +1100 Kevin Elphinstone (KE) wrote:

KE> * System-level priority ceiling protocol (static assignment of
KE> priorities) with priority preserving lazy scheduling, i.e. lazy switch
KE> only happens if destination is (equal) highest priority thread.
KE> 
KE> 	- I beleive we have something that approximates this at NICTA, maybe
KE> 	dresden has this also. 

I don't believe we have something like this in Dresden or I'm not understanding
why lazy switching should be done only if destination is equal highest-priority
thread in this case.

KE> * system-level priority inheritance (or call it persistent time-slice
KE> donation if you wish), this is what I believe dresden is talking about,
KE> has proposed, and I gather have not implemented. It requires tracking of
KE> dependencies of IPC in some manner.

The proposed mechanism can do priority inheritance and stack-based priority
ceiling on top of L4 with some tracking added to the IPC path.

KE> My point, everybody is "correct" depending on what you are
KE> doing/expecting at the system level.

Sure.

KE> So rather than argue over details of how lazy-scheduling "should" or
KE> does behave, one should have a clear idea of what is required at the
KE> system level, and what model of the three above is required (or maybe an
KE> alternative), or maybe an existing model with restrictions on what one
KE> can do.

There has been no argument but rather a discussion of issues that exist in
the current L4 implementations. Whether these issues matter in a particular
system design is entirely dependent on what your real-time requirements are
or rather, whether you have any.

I know these issues have been debated to death in the past and to some of us
the implications are pretty clear - but I didn't start this thread ;)

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