Please summarize isr SMP changes

[Sebastian Huber]

Hello Joel,

On 2013-08-05 16:20, Joel Sherrill wrote:
> Hi
>
> I can't tell what the ultimate result of all these changes is. I see code using the per CPU structure without indexing it but can't tell if that is uniprocessor specific.

the code without indexing the _Per_CPU_Information is only in the restored 
interrupt entry/exit code.  I used separate commits since you can then get a 
diff to the original code without SMP.

Please compare that changes in

[PATCH 08/12] bsps/sparc: Per-CPU thread dispatch disable

[PATCH 12/12] bsps/i386: SMP and per-CPU thread dispatch disable

with the changes previously necessary to add SMP support for the interrupt 
entry/exit.

Since these previous SMP support changes were quite complex and introduced bugs

https://www.rtems.org/bugzilla/show_bug.cgi?id=2082

http://git.rtems.org/rtems/commit/?id=e94aa61b6820e34732840139dbe3f2016c6f1e24

I reverted them to get a clean start point.

>
> Can you please write up the intended design/behavior?

The main change is in

[PATCH 04/12] score: Per-CPU thread dispatch disable level

It introduces a per-CPU thread dispatch disable level.  So instead of one 
global thread dispatch disable level we have now one instance per processor.

We still have the giant lock, but it is now decoupled from the thread 
dispatching in _Thread_Dispatch() and _Thread_Handler().

As a side-effect this fixes the lost thread dispatch necessary
indication bug in _Thread_Dispatch().

A per-CPU thread dispatch disable level greatly simplifies the SMP
support for the interrupt entry/exit code since no spin locks have to be
acquired in this area.  It is only necessary to get the current
processor index and use this to calculate the address of the own per-CPU
control.  This reduces the interrupt latency considerably.

All elements for the interrupt entry/exit code are now part of the 
Per_CPU_Control structure: thread dispatch disable level, ISR nest level and 
thread dispatch necessary.  Nothing else is required (except CPU port specific 
stuff like on SPARC).

The giant lock is only acquired for high-level operations in interrupt
handlers (e.g. release of a semaphore, sending of an event).

> Ultimately that needs to be in the porting guide.

Yes, I think we will start soon with such a thing.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
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.