I think you missed the important part: there must be no false sharing with
If you have a 4-byte entry that is aligned to 128 bytes, you have 124
bytes of stuff that the linker _will_ fill up with other things.
And if you don't want false sharing, that MUST NOT HAPPEN.
Try it. You'll see.
> Separate sections are also not needed. While you can't guarantee
> adjacency, the object file *does* record the required alignment
> and that must be honored by the linker.
It's not just alignment: it wants an exclusive cacheline. Thus the
And I'm claiming, based on past experiences with the linker, that the
padding won't guarantee anything, because the linker can re-order things
to "pack" them tighter. So the padding either has to be inside a structure
or a union (which implies a new type, and thus that the users care about
whether the spinlock is padded or not), or it needs a separate section, so
that it doesn't _matter_ if the linker re-orders anything, because
everything in that section is aligned, and as such you cannot get false
sharing even with reordering.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/