SMP cache synchronisation

[Daniel Hellstrom]

On 10/24/2013 03:33 PM, Gedare Bloom wrote:
> On Thu, Oct 24, 2013 at 9:15 AM, Daniel Hellstrom <daniel at gaisler.com> wrote:
>> Hello,
>>
>>  From code analysis and testing SMP on LEON I can see that when installing a
>> trap handler the cache is not invalidated correctly on other CPUs then the
>> CPU installing the new trap handler. In the single-core case this is
>> correct, but for SMP we must flush all CPUs caches. I think this is a
>> platform independent problem for all self-modifying code. On the LEON SMP we
>> normally don't see this since since the bad traps that are installed are
>> never taken.
>>
>> My suggestion is that we use a IPI to signal to other CPUs to invalidate
>> their instruction cache, and CPU requesting such a remote CPU(s) flush
>> should wait until all remote CPUs signal that their cache has been
>> invalidated. The cache library could be extended to support SMP. Perhaps is
>> should not be a platform independednt IPI solution, but rather a libcpu/BSP
>> specific implementation for implementing cache flush on another CPU?
>>
> Why wait for a response? Rather, is there a need for both synchronous
> and asynchronous versions of the remote cache operations?
If the trap is installed and don't wait on other CPUs, then something is enabled that causes traps to happen then secondary CPU have not the correct trap handler.

>
> I think the cache manager should certainly be extended with SMP
> capabilities. We should identify which operations make sense to invoke
> on a remote core, and which operations make sense to invoke on all
> cores. This can simplify the interface by making some operations
> implicitly work on SMP, for example cache_invalidate_entire_data()
> could be made to invalidate the data cache on every core if that
> semantic makes sense.
make sens to extend the cache manager. I agree.

Daniel

>
> -Gedare
>
>> What do think about this issue?
>>
>> Regards,
>> Daniel Hellstrom
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel