Messages in this thread | | | Date | Fri, 28 Jan 2005 05:28:15 +0100 | From | Ingo Molnar <> | Subject | Re: [patch, 2.6.10-rc2] sched: fix ->nr_uninterruptible handling bugs |
| |
* Paul Jackson <pj@sgi.com> wrote:
> A long time ago, Linus wrote: > > An atomic op is pretty much as expensive as a spinlock/unlock pair on x86. > > Not _quite_, but it's pretty close. > > Are both read and modify atomic ops relatively expensive on some CPUs, > or is it just modify atomic ops? > > (Ignoring for this question the possibility that a mix of read and > modify ops could heat up a cache line on multiprocessor systems, and > focusing for the moment just on the CPU internals ...)
if by 'some CPUs' you mean x86 then it's the LOCK prefixed ops that are expensive. I.e. all the LOCK-prefixed RMW variants of instructions:
atomic.h: LOCK "addl %1,%0" atomic.h: LOCK "subl %1,%0" atomic.h: LOCK "subl %2,%0; sete %1" atomic.h: LOCK "incl %0" atomic.h: LOCK "decl %0" atomic.h: LOCK "decl %0; sete %1" atomic.h: LOCK "incl %0; sete %1" atomic.h: LOCK "addl %2,%0; sets %1" atomic.h: LOCK "xaddl %0, %1;" atomic.h:__asm__ __volatile__(LOCK "andl %0,%1" \ atomic.h:__asm__ __volatile__(LOCK "orl %0,%1" \
pure reads/writes are architecturally guaranteed to be atomic (so atomic.h uses them, not some fancy instruction) and they are (/better be) fast.
interestingly, the x86 spinlock implementation uses a LOCK-ed instruction only on acquire - it uses a simple atomic write (and implicit barrier assumption) on the way out:
#define spin_unlock_string \ "movb $1,%0" \ :"=m" (lock->slock) : : "memory"
no LOCK prefix. Due to this spinlocks can sometimes be _cheaper_ than doing the same via atomic inc/dec.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |