read_cpuid_id() in arch/arm/kernel/setup.c

[mark.rutland@arm.com (Mark Rutland)]

On Fri, Mar 13, 2015 at 05:02:51PM +0000, Russell King - ARM Linux wrote:
> On Fri, Mar 13, 2015 at 04:56:00PM +0000, Mark Rutland wrote:
> > In the presence of big.LITTLE the comment and premise of the
> > optimisation here is wrong. A thread can migrate between cores of
> > differing microarchitectures.
> > 
> > So __attribute_const__ is simply broken, and we probably need to do
> > something like the black magic SP hazarding hack we do for the tpidr
> > percpu accesses (only expecting this to be called in non-preemptible
> > context) if it makes sense to allow the value to be cached.
> 
> Yes, it's true that with big.LITTLE, lots of stuff is broken in this
> regard, and you are partially right, but you are not entirely right
> either.
> 
> It's not the reading of the CPU ID which is the problem, it's the
> reading _and_ use of derived results which is a problem.

I don't dispute that, and my comment was not meant to imply that.

> What this basically means is that in the presence of big.LITTLE, we
> need __get_cpu_architecture() as a whole, and whatever makes use of
> its return value to /all/ be non-preemptible... and probably a lot
> more code too.

Sure; this is exactly like using percpu variables, as I mentioned above.
The criticial section at which it is meaningful to read, perform some
work, and write back needs to be bound to a particular CPU.

I guess you could allow for preemption so long as the thread stayed
bound to the same CPU -- the ID registers aren't going to change on the
same CPU because another thread was running for a while. I don't know if
it would be possible to do any black magic hazarding to allow for that
though.

Mark.