On Fri, Oct 12, 2007 at 11:55:05AM +0200, Jarek Poplawski wrote:It's not. Not in the cases where it is explicitly allowed and actively exploited (loads passing stores), but most definitely not distinctly visible in errata cases that have slipped through all the V&V. Yes: it isn't the explicitly allowed reorderings that we care about here (because obviously we're retaining the barriers for those). It would be cases of bugs in the CPUs meaning they don't follow the standard. But how far do you take your mistrust of a CPU? You could ask gcc to insert locked ops between every load and store operation? Or keep it switched off to ensure no bugs ;) Firstly, while it can be possible to write a code to show up reordering, it is really hard (ie. impossible) to guarantee no reordering happens. For example, it may have only showed up on SMT+SMP P4 CPUs with some obscure interactions between threads and cores involving more than 2 threads. Secondly, even if we were sure that no current implementations reordered loads, we don't want to go outside the bounds of the specification because we might break on some future CPUs. This isn't a big performance win. Yes, but that's the same way I feel after reading *any* legal "information" ;) -
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Antonio Almeida | HTB accuracy for high speed |
| David Miller | [GIT]: Networking |
