On Mon, May 11, 2015 at 7:54 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> Hmm, so I looked at the set_mb() definitions and I figure we want to do
> something like the below, right?
I don't think you need to do this for the non-smp cases. The whole
thing is about smp memory ordering, so on UP you don't even need the
WRITE_ONCE(), much less a barrier.
That said, I do wonder if we should make that "it's only an smp
barrier" more explicit. We have non-smp barriers for people who do
DMA, and while they should probably never use anything like set_mb()
anyway (they tend to want *release* semantics, not a full barrier),
from a conceptual standpoint the "set_mb()" function really is closer
to the "smp_store_release()/smp_load_acquire()" family of macros.
So I wonder if we should change the name to match.
IOW, if we are really cleaning up smp_mb() and changing most of the
lines associated with it (we really have very few users, and there
seems to be more lines *defining* smp_mb() than there are lines
*using* it in the kernel), maybe we should also just rename it
"smp_store_mb()" at the same time.
I dunno. Maybe the churn isn't worth it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|