> Um, OK, you've said write twice now ... I was assuming you meant read. > Even on an x86, writes are posted, so there's no way a spin lock could > serialise a write without an intervening read to flush the posting > (that's why only reads have a relaxed version on altix). Or is there > something else I'm missing? Writes are posted yes, but not reordered arbitrarily. If I have code like: spin_lock(&mmio_lock); writel(val1, reg1); writel(val2, reg2); spin_unlock(&mmio_lock); then I have a reasonable expectation that if two CPUs run this at the same time, their writes to reg1/reg2 won't be interleaved with each other (because the whole section is inside a spinlock). And Altix violates that expectation. - R. --
| Andreas Gruenbacher | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| Alan Cox | Re: [patch 7/8] fdmap v2 - implement sys_socket2 |
| Jens Axboe | Re: regression: CD burning (k3b) went broke |
| Paul E. McKenney | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
git: | |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| David Miller | [GIT]: Networking |
| Alexey Dobriyan | [PATCH 09/33] netns ct: per-netns /proc/net/nf_conntrack, /proc/net/stat/nf_conntr... |
| Gerrit Renker | [PATCH 18/37] dccp: Support for Mandatory options |
