Dynamic switching of co-processor context

[Peter Dufault]

On Oct 14, 2009, at 10:19 , Sebastian Huber wrote:
>
> This discussion focus on the PowerPC, but other architectures may be  
> similar.
>
> Suppose you have a co-processor (floating-point, digital signal  
> processing,
> vector unit) which only few tasks need (more than one) or that is  
> seldom used
> by tasks (printf() for example), then it is desirable to remove the
> co-processor context switching from the normal context switch.

I'll immediately grant "it is often desirable to remove the resource  
context switch time", but I'm not yet convinced it is always desirable.

> The separation
> of the context switching results in a reduced context switch time.   
> This
> reduces also the worst case time of disabled interrupts (= worst  
> case interrupt
> latency WCIL).  On the PowerPC the WCIL is very likely this sequence:
>
>  1. An interrupt handler finishes its work
>  2. External exceptions are disabled at the end of interrupt  
> processing
>  3. First half of the exception epilogue
>  4. A context switch is necessary
>  5. Context switch to a task that was suspended by an interrupt

Isn't that context still active?  I thought the interrupt saves its  
own context, separately from thread context, and that won't include  
the resource context.  If I have that wrong that could explain the  
brokenness of my prototype for PowerPC SPE context save/restore (where  
the idle task returns if I interrupt it in the debugger).  Or is that  
what you mean in your follow up clarification "The WCIL is the worst  
case time of disabled interrupts plus the
exception prologue time"?

This email will go over what I see as the advantages and disadvantages  
of lazy context switching.  Please stop reading now if I'm wrong about  
basic exception handling.

Advantages:
A1: The context switch to a higher priority task that doesn't use the  
resource is minimal.
A2: In the case of a single thread using the resource there is NO  
context switching overhead at all.
A3: In the case of multiple resources there is no scaling issue as the  
context switch takes longer.  Threads only incur the expense of  
switching the resource they use.

Disadvantages:
D1: The context switch-in becomes more indeterminate.  A switched-to  
thread may have no overhead, or it may need to save the current  
owner's context as well as restore its own context, and that depends  
on which threads are runnable and where they are in their processing.
D2: If the resource is allocated via an exception you incur the  
overhead of an exception the first time you use a resource and any  
time you are activated when another thread owns it.  With multiple  
resources you get multiple exceptions.
D3: There are more corners for bugs to hide in.

Some of these fight each other.  A3, where there are many resources,  
and D1, where switch-in time becomes difficult to quantify, could have  
quite a battle.

I like most of my real-time applications to be as constantly loaded as  
possible, often doing calculations and then throwing away the results  
to attain that.

Am I correct about the exceptions not being impacted by this?  Are  
there other Advantages / Disadvantages to add to my list?

Peter