On Wed, Jul 08, 2009 at 12:34:32AM -0400, Mathieu Desnoyers wrote: ...It's completely backwards: processor barriers are just expected to add a performance degradation. That's like: x86 developer: OK, we need to add a barrier here: even x86 might need this. Alpha developer: Right, than we need this even more. x86 developer: But wait, we can avoid it using a dummy after some locks, because they have such a barrier already. Alpha developer: Then it's not OK: it's _only_ useful on x86; our architecture _will_ suffer from a performance degradation... Cheers, Jarek P. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Andrea Arcangeli | [PATCH 00 of 12] mmu notifier #v13 |
| Eric W. Biederman | Remaining straight forward kthread API conversions... |
| Eric Paris | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Trond Myklebust | Re: Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | [PATCH 04/33] Fix {ip,6}_route_me_harder() in netns |
