Messages in this thread | | | Date | Wed, 8 Jul 2009 09:18:31 +0200 | From | Jarek Poplawski <> | Subject | Re: [PATCHv5 2/2] memory barrier: adding smp_mb__after_lock |
| |
On Wed, Jul 08, 2009 at 12:34:32AM -0400, Mathieu Desnoyers wrote: ... > Because adding smp_mb__after_lock() is _only_ useful on x86. Most other > architectures _will_ suffer from a performance degradation, unless you > implement the __read_lock_noacquire.
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.
| |