SMP cache synchronisation

[Gedare Bloom]

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?

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.

-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