On Wed, Oct 17, 2007 at 01:05:16AM +0200, Mikulas Patocka wrote:What do you mean "already"? If we already have drivers loading data from WC memory, then rmb() needs to order them, whether or not they actually need it. If that were prohibitively costly, then we'd introduce a new barrier which does not order WC memory, right? You mean the one defined like this: #define wmb() asm volatile("sfence" ::: "memory") ? If it assumed writes are ordered, then it would just be a barrier(). Most tend to order them strongly these days. There are also relaxed variants for architectures that can take advantage of them. I don't understand why you say wmb() doesn't work on WC memory. What part of which spec are you reading (or, given your mistrust of specs, what CPU are you seeing failures with)? Well it clearly is the case because I just pointed you to a document that says they can go out of order. If you want to argue that existing implementations do not, then by all means go ahead and send a patch to Linus and see what he says about it ;) -
| Andrew Morton | -mm merge plans for 2.6.23 |
| Benjamin Herrenschmidt | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Mel Gorman | [PATCH 6/8] x86_64 - Specify amount of kernel memory at boot time |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | Re: Soft-Lockup/Race in networking in 2.6.31-rc1+195 ( possibly?caused by netem) |
