Dynamic switching of co-processor context

[Sebastian Huber]

Peter Dufault wrote:
> 
> 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?  

5. Context switch to another task (not the task currently interrupted) that was
suspended by an interrupt

> I thought the interrupt saves its own
> context, separately from thread context, and that won't include the
> resource context.  

This is correct.

> 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).  

I don't know how this can happen.

> 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?

Exceptions are impacted by this, since they own the MSR of the interrupted
task.  The real MSR of the interrupted task is on the exception stack.  Some
care has to be taken to get this right.

I think that is a good advantages / disadvantages list.  In the end it will be
application dependent if a lazy context switch is desirable or not.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.