shared memory problem on ARM v5TE using threads

Russell King - ARM Linux linux at arm.linux.org.uk
Fri Dec 18 14:16:26 EST 2009


On Fri, Dec 18, 2009 at 07:45:19PM +0100, Pavel Machek wrote:
> But that's pretty unusual situation, right?

It may be uncommon, but it's something that must work - not only is it
a quality of implementation issue, but its also a data corruption issue.
Get it wrong and you silently corrupt files on your filesystems.

As I've said earlier in the thread, we know that db4 does this.  Not
fixing this means that we really don't care about any program which
uses db4, or data contained within a db4 database.

> So what about...
> 
> a) flush L2 on context switch

If you go to that extent, the system will probably perform better with
the L2 cache permanently disabled.

> b) disable L2 when thread has maps one physical address twice

Due to the way the L2 cache works, you have to disable L2 and flush it
when switching to the thread, and re-enable L2 when you switch away.
Merely flushing it when switching away won't work.

In order to disable or enable the L2 cache, the L1 cache must be
flushed and disabled - and that would have to be done with all IRQs
(including FIQs) disabled to ensure that its done atomically.

I don't think this is a sane option.



More information about the linux-arm-kernel mailing list