RE: SMP Scheduling

[Jan Stoess]
>> 
>> - Threads have priorities. Threads in one priority class are served
>> round-robin. Higher priority queues are served first.

> That's correct except for the UP-IPC path, where the scheduler is
> shortcut in favor of a timeslice donation scheme. The SMP-IPC, path
> again uses the scheduler, however, since synchronization (e.g., via
> IPIs) is needed anyway.

 
>> - A thread has a timeslice size and a "total quantum". Each time
>> the thread is preempted (or calls L4_Yield), the time it has
>> consumed is subtracted from the total quantum until it is
>> depleted. At this point the thread's scheduler gets a preemption
>> message.
>> - Whether the preemption message is delivered to the scheduler or
>> not, a thread's quantum is reset to its initial value and the
>> thread is runnable again.
>> - Because preemption messages are sent with timeout 0, one would
>> need at least one thread per CPU that handles preemption
>> messages. Otherwise one could lose messages when the scheduler is
>> busy.

> That's true with respect to the X.2 spec. The current implementation
> doesn't use timeout 0, however, as you can see in
> tcb_t::send_preemption_ipc(u64_t time) in
> kernel/src/api/v4/thread.cc. Afaik no-one has really used preemption
> messages in the original L4KA:Pistachio. I know of several
> prototypes addressing scheduling problems in L4, but no official
> version is available (yet).
 
I did an implementation that used infinite timeout and required a
reply fromm the scheduler as well.  Also, I added support for IPCs
upon all preemptions and/or preemptions due to end-of-timeslice.  I'm
not sure if Jan or other people wants support for this in mainline
Pistachio.

The modifications to support this sound trivial, but they require a
bit of restructuring inside the kernel to avoid having several layers
of nested IPCs (which consumes too much kernel stack space).

	eSk