L1 & L2 cache flush sequence on CortexA5 MPcore w.r.t low power modes
Russell King - ARM Linux
linux at arm.linux.org.uk
Tue May 15 05:40:10 EDT 2012
On Mon, May 14, 2012 at 06:15:33PM +0100, Lorenzo Pieralisi wrote:
> On Mon, May 14, 2012 at 05:39:09PM +0100, Russell King - ARM Linux wrote:
> > From what you're saying - and from my understanding of your cache behaviours,
> > even the sequence:
> > - clean cache
> > - disable C bit
> > - clean cache
> > is buggy.
>
> No, that's correct, works fine on A9 and A15. Second clean is mostly nops.
It's racy. Consider this:
- clean cache
- cache speculatively prefetches a dirty cache line from another CPU
- disable C bit
At this point, you lose access to that dirty data. If that dirty data is
used inbetween disabling the C bit and cleaning the cache for the second
time, you have data corruption issues.
Another point which needs to be checked is whether dirty cache lines in
a CPUs cache which has had the C bit disabled still take part in the
coherency protocol with other CPUs. If the answer is no, then that's a
_major_ problem for the hot unplug code paths. That effectively means
that we have a window where a CPU going down actively _corrupts_ the
data visible to other CPUs.
As I have said, given what you've mentioned, it is impossible to safely
disable the cache on a SMP system. In order to do it safely, you need to
have a way to disable new allocations into the cache _without_ disabling
the ability for the cache to be searched.
And if we could do that, then the sequence becomes a simple and race free:
- disable new allocations
- clean cache
- disable cache
More information about the linux-arm-kernel
mailing list