Instances of lazy scheduling and timeslice donation in L4 implementations
Espen Skoglund
esk at ira.uka.de
Tue Jan 24 21:54:27 CET 2006
[Udo A Steinberg]
> On Tue, 24 Jan 2006 19:54:29 +0100 Espen Skoglund (ES) wrote:
ES> Speaking for the Pistachio implementation: The time is accounted to
ES> the thread who currently "owns" the timeslice (thread A in this case).
ES> Each time a timer tick occurs, and there are no preemptions by higher
ES> priority threads, thread B will run on the time donated by thread A.
ES> This is according to the spec.
> So far all is clear.
ES> Once the timeslice expires a new
ES> scheduling decision is made. This may or may not cause thread B to
ES> continue running (depending on priorities, scheduling queues, etc.).
> This is also clear.
> The tricky case is as follows:
> 1) A performs a thread_switch syscall, donating its time slice to B
> 2) B executes and consumes part of A's time (but not all)
> 3) B is preempted by a higher-priority thread H
> 4) H blocks
> How does B get to consume the remainder of A's time slice, i.e. the
> part that it did not use up in 2) ?
Sorry for not being precise enough here. True, if preemted while
running on the donated timeslice the remainder of the timeslice will
no longer be donated. One could think of a scheme that maintained the
timeslice donation state across such preemptions. One might even come
up with a solution that does not require any modifications on the fast
IPC path. It would complicate the scheduling code a little, though.
How this would affect the scheduler performance I can not tell.
eSk
More information about the l4-hackers
mailing list