> > Would it be worth renaming the mb/rmb/wmb to io_mb/io_rmb/io_wmb?
> > After all, I believe they should only be used to flush I/O memory
> > accesses. This would, I think, make the distinction between memory
> > barriers for I/O and memory barriers for SMP more obvious.
>
> Are you joking or genuinely confused?
To be fair there are a lot of confused people out there. A few examples:
1. My original patch showed there are a number of places we use memory
barriers on UP when not required. Getting rid of mb/rmb/wmb would help
this, people are unlikely to sprinkle io_mb in the scheduler code :)
2. drivers/net/typhoon.c
INIT_COMMAND_NO_RESPONSE(cmd, TYPHOON_CMD_HELLO_RESP);
smp_wmb();
writel(ring->lastWrite, tp->ioaddr + TYPHOON_REG_CMD_READY);
it looks a lot like smp_wmb is being used to order IO.
3. On ppc64 we recently had to upgrade our barriers to make sure
mb/wmb/rmb ordered IO. This is because drivers do this (example taken
from e1000):
tx_desc->lower.data |= cpu_to_le32(adapter->txd_cmd);
/* Force memory writes to complete before letting h/w
* know there are new descriptors to fetch. (Only
* applicable for weak-ordered memory model archs,
* such as IA-64). */
wmb();
tx_ring->next_to_use = i;
E1000_WRITE_REG(&adapter->hw, TDT, i);
Renaming mb/wmb/rmb to io_mb/io_wmb/io_rmb would fit in well here.
4. Its not clear other architectures are insuring wmb/rmb/mb are
ordering IO. Checking ia64:
* Note: "mb()" and its variants cannot be used as a fence to order
* accesses to memory mapped I/O registers. For that, mf.a needs to
* be used. However, we don't want to always use mf.a because (a)
* it's (presumably) much slower than mf and (b) mf.a is supported for
* sequential memory pages only.
Anton
