Re: L4_ThreadSwitch behaviour

On Feb 22, 2007, at 1:25 AM, Espen Skoglund wrote:

> [Martin Christian]
>> My question is related to both L4Ka::Pistachio and
>> NICTA::Pistachio-embedded, thus I'm mailing to both lists.
>
>> Consider the following test cases:
>
>> Case A
>> ======
>> 1. The root thread creates a new thread in a new address space (AS):
>> 2. The root thread "refills" it's time slice (maybe that's bogus,  
>> but it
>> is meant to ensure a full time slice is donated): L4_Yield();
>> 3. The root thread donates the rest of it's time slice to the new
>> thread:
>>    L4_ThreadSwitch( ping_tid );
>
>> Case B
>> ======
>> 1. The root thread creates a new thread in a new AS
>> 2. The root thread waits for a startup IPC from the new thread (of
>> course, the new thread has to be altered to send such an IPC)
>> 3. The root thread "refills" it's time slice
>> 4. The root thread donates the rest of it's time slice to the new  
>> thread
>
>> Problem:
>> Case A won't work, but Case B does. For Case A the new thread  
>> won't run,
>> even though it's active and in the ready queue. The only  
>> difference is
>> that in Case B the pages which hold the code are already mapped in  
>> the
>> new threads AS.
>
> A bit late for me to jump in, but I'll do it anyway.
>
> As you've already been told, doing scheduling purely based on
> timeslice donation is not a very good idea.

What other options are there for implementing user-level scheduling  
policy?

Also, is there any way to account for all CPU time at the user  
level?  Eg. how could one implement top(1)?

> Even if you manage to
> donate almost a complete timeslice there is no telling how much of the
> timeslice you'll manage to consume due to interrupts, exception
> handling, etc.
>
> In your case I suspect that handling the page faults in the new thread
> will consume quite a bit of your timeslice.

That alone isn't reason to abandon timeslice donation, IMO.  All the  
page fault handling happened on behalf of the new thread.  An OS  
design might see it as an advantage that services performed on behalf  
of a thread use that thread's time.

Josh