Re: v7_flush_kern_cache_louis flushes up to L2?

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Fri, Apr 19, 2013 at 11:21:42AM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 10, 2013 at 02:35:05PM +0100, Jonathan Austin wrote:
> > Note that on SMP, you would also need to clean/flush again after turning  
> > off the caches, as read-speculation could have sucked dirty data from  
> > another cache in to your cache, which would need to be written back  
> > before sleeping.
> 
> Err, no.  If you read data into a cache, it is always populated in a clean
> state.  You never suck dirty data out of one cache, remove it there and
> place it immediately in a dirty state in an upper level cache.
> 
> So, if we start from the idea that reads will populate the upper level
> cache with clean data, that cache is populated merely with a _copy_ of
> the data held elsewhere in the system.

Hmm, Will tells me that later ARM cores can migrate dirty cache lines up
the cache tree, which means that we're potentially into deep problems
with CPU hotplug and suspend paths, because it means there's potentially
no way to ensure that we cleanly push data out the caches and shut the
caches down before the CPU goes down.

Combine this cache behaviour with the implementation specific details
about SCTRL.C (whether caches are just prevented from being allocated,
or whether it also affects the caches being searched) and you have a
recipe for multiple chunks of complex platform specific and CPU
specific code - especially when combined with things like removal of
CPU power and synchronisation of that in the hotplug case.

I do hope that ARM Ltd have thought about this, and have a way that we
can shut CPU caches down sanely, but I'm fearing that they haven't
really considered that to be something anyone really wants to do in a
generic way.