shared memory problem on ARM v5TE using threads

[Ronen Shitrit]

-----Original Message-----
From: Heiko Schocher [mailto:hs at denx.de] 
Sent: Monday, December 07, 2009 2:24 PM
To: Russell King - ARM Linux
Cc: saeed bishara; Ronen Shitrit; linux-arm-kernel at lists.infradead.org
Subject: Re: shared memory problem on ARM v5TE using threads

Hello Russell,

Russell King - ARM Linux wrote:
> On Mon, Dec 07, 2009 at 01:31:41PM +0200, saeed bishara wrote:
[...]
>>> If there's no problem with C=0 B=1 mappings on Kirkwood, I've no idea
>>> what's going on, and I don't have any suggestion on what to try next.
>>>
>>> The log shows that the kernel is doing the right thing: when we detect
>>> two mappings for the same page in the same MM space, we clean and
>>> invalidate any existing cacheable mappings visible in the MM space
>>> (both L1 and L2), and switch all visible mappings to C=0 B=1 mappings.
>>> This makes the area non-cacheable.
>> what about the PTE of the MM space of the write process? if it remains
>> C=1 B=1, then it's data will be at the L2, and as the L2 is not
>> flushed on context switch, then that explains this behavior.
> 
> That's probably the issue, and it means that _all_ shared writable
> mappings on your processor will be broken.

Hmm.. I tried also the testprg with CACHE_FEROCEON_L2 deaktivated,
same result ...

> Oh dear, that really is bad news.

Indeed.

> There are two solutions to this which I can currently think of:
> 1. flush the L2 cache on every context switch

To clarify, the testprg runs fine, if I start 4 processes each with
only one read thread. In this case all works as expected. The mess
begins only, if one read process starts more than one read thread ...

[Ronen Shitrit] That also match the theory:
When using different processes, the shared area will stay C=1 B=1, 
On each context switch L1 will be flushed,
Since L2 is PIPT next process will get the correct data...