[PATCH] arm64: smp: Add a memory barrier before we start secondary cores

Mark Brown broonie at kernel.org
Thu Feb 13 10:58:37 EST 2014

On Wed, Feb 12, 2014 at 06:23:14PM +0000, Catalin Marinas wrote:

> I think we should aim to understand the code better rather than just
> adding the spinlocks. Some simple questions:

I agree that understanding the code is good, my point is that if the
code needs serious thinking about to understand then it's probably not
good code even if it is correct given that it's not super performance

> - Who uses the topology information and when? (the scheduler? first time after or
> before secondaries are started?)

It's used directly by the architecture topology code only (to generate
information read by the scheduler).  The scheduler appears to deal with
its own concurrency requirements and it appears to use information it
gets immediately.

> - Who updates the topology information? (primary and secondary startup
> code?)

Each CPU that comes on line.

> - What about hotplug?

Removal currently doesn't do anything to these data structures (nor is
it expected to).  Starting the CPU will redo the startup code which
should produce the same result again (anything dynamic would need work
to support dynamic topology information anyway).

> - Can any of the above happen in parallel on different CPUs?

Everything looks serialised, though I may be missing some cases or have
lost something in an indirection.

A lack of locking also seems reasonably consistent with other
architectures from a quick survey.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140213/07be9ae2/attachment.sig>

More information about the linux-arm-kernel mailing list