2007-05-08 15:35:02 +08:00
|
|
|
#ifndef __ASM_CMPXCHG_H
|
|
|
|
#define __ASM_CMPXCHG_H
|
|
|
|
|
|
|
|
#include <linux/bitops.h> /* for LOCK_PREFIX */
|
|
|
|
|
2007-07-19 19:30:14 +08:00
|
|
|
/*
|
|
|
|
* Note: if you use set64_bit(), __cmpxchg64(), or their variants, you
|
|
|
|
* you need to test for the feature in boot_cpu_data.
|
|
|
|
*/
|
|
|
|
|
2008-03-23 16:01:51 +08:00
|
|
|
#define xchg(ptr, v) \
|
|
|
|
((__typeof__(*(ptr)))__xchg((unsigned long)(v), (ptr), sizeof(*(ptr))))
|
2007-05-08 15:35:02 +08:00
|
|
|
|
2008-03-23 16:01:51 +08:00
|
|
|
struct __xchg_dummy {
|
|
|
|
unsigned long a[100];
|
|
|
|
};
|
2007-05-08 15:35:02 +08:00
|
|
|
#define __xg(x) ((struct __xchg_dummy *)(x))
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The semantics of XCHGCMP8B are a bit strange, this is why
|
|
|
|
* there is a loop and the loading of %%eax and %%edx has to
|
|
|
|
* be inside. This inlines well in most cases, the cached
|
|
|
|
* cost is around ~38 cycles. (in the future we might want
|
|
|
|
* to do an SIMD/3DNOW!/MMX/FPU 64-bit store here, but that
|
|
|
|
* might have an implicit FPU-save as a cost, so it's not
|
|
|
|
* clear which path to go.)
|
|
|
|
*
|
|
|
|
* cmpxchg8b must be used with the lock prefix here to allow
|
|
|
|
* the instruction to be executed atomically, see page 3-102
|
|
|
|
* of the instruction set reference 24319102.pdf. We need
|
|
|
|
* the reader side to see the coherent 64bit value.
|
|
|
|
*/
|
2008-03-23 16:01:51 +08:00
|
|
|
static inline void __set_64bit(unsigned long long *ptr,
|
|
|
|
unsigned int low, unsigned int high)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("\n1:\t"
|
|
|
|
"movl (%0), %%eax\n\t"
|
|
|
|
"movl 4(%0), %%edx\n\t"
|
|
|
|
LOCK_PREFIX "cmpxchg8b (%0)\n\t"
|
|
|
|
"jnz 1b"
|
|
|
|
: /* no outputs */
|
|
|
|
: "D"(ptr),
|
|
|
|
"b"(low),
|
|
|
|
"c"(high)
|
|
|
|
: "ax", "dx", "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
}
|
|
|
|
|
2008-03-23 16:01:51 +08:00
|
|
|
static inline void __set_64bit_constant(unsigned long long *ptr,
|
|
|
|
unsigned long long value)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
2008-03-23 16:01:51 +08:00
|
|
|
__set_64bit(ptr, (unsigned int)value, (unsigned int)(value >> 32));
|
2007-05-08 15:35:02 +08:00
|
|
|
}
|
|
|
|
|
2008-03-23 16:01:51 +08:00
|
|
|
#define ll_low(x) *(((unsigned int *)&(x)) + 0)
|
|
|
|
#define ll_high(x) *(((unsigned int *)&(x)) + 1)
|
|
|
|
|
|
|
|
static inline void __set_64bit_var(unsigned long long *ptr,
|
|
|
|
unsigned long long value)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
2008-03-23 16:01:51 +08:00
|
|
|
__set_64bit(ptr, ll_low(value), ll_high(value));
|
2007-05-08 15:35:02 +08:00
|
|
|
}
|
|
|
|
|
2008-03-23 16:01:51 +08:00
|
|
|
#define set_64bit(ptr, value) \
|
|
|
|
(__builtin_constant_p((value)) \
|
|
|
|
? __set_64bit_constant((ptr), (value)) \
|
|
|
|
: __set_64bit_var((ptr), (value)))
|
2007-05-08 15:35:02 +08:00
|
|
|
|
2008-03-23 16:01:51 +08:00
|
|
|
#define _set_64bit(ptr, value) \
|
|
|
|
(__builtin_constant_p(value) \
|
|
|
|
? __set_64bit(ptr, (unsigned int)(value), \
|
|
|
|
(unsigned int)((value) >> 32)) \
|
|
|
|
: __set_64bit(ptr, ll_low((value)), ll_high((value))))
|
2007-05-08 15:35:02 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: no "lock" prefix even on SMP: xchg always implies lock anyway
|
|
|
|
* Note 2: xchg has side effect, so that attribute volatile is necessary,
|
|
|
|
* but generally the primitive is invalid, *ptr is output argument. --ANK
|
|
|
|
*/
|
2008-03-23 16:01:51 +08:00
|
|
|
static inline unsigned long __xchg(unsigned long x, volatile void *ptr,
|
|
|
|
int size)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
|
|
|
switch (size) {
|
2008-03-23 16:01:51 +08:00
|
|
|
case 1:
|
|
|
|
asm volatile("xchgb %b0,%1"
|
|
|
|
: "=q" (x)
|
|
|
|
: "m" (*__xg(ptr)), "0" (x)
|
|
|
|
: "memory");
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
asm volatile("xchgw %w0,%1"
|
|
|
|
: "=r" (x)
|
|
|
|
: "m" (*__xg(ptr)), "0" (x)
|
|
|
|
: "memory");
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
asm volatile("xchgl %0,%1"
|
|
|
|
: "=r" (x)
|
|
|
|
: "m" (*__xg(ptr)), "0" (x)
|
|
|
|
: "memory");
|
|
|
|
break;
|
2007-05-08 15:35:02 +08:00
|
|
|
}
|
|
|
|
return x;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Atomic compare and exchange. Compare OLD with MEM, if identical,
|
|
|
|
* store NEW in MEM. Return the initial value in MEM. Success is
|
|
|
|
* indicated by comparing RETURN with OLD.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_CMPXCHG
|
|
|
|
#define __HAVE_ARCH_CMPXCHG 1
|
2008-03-23 16:01:51 +08:00
|
|
|
#define cmpxchg(ptr, o, n) \
|
|
|
|
((__typeof__(*(ptr)))__cmpxchg((ptr), (unsigned long)(o), \
|
|
|
|
(unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))))
|
|
|
|
#define sync_cmpxchg(ptr, o, n) \
|
|
|
|
((__typeof__(*(ptr)))__sync_cmpxchg((ptr), (unsigned long)(o), \
|
|
|
|
(unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))))
|
|
|
|
#define cmpxchg_local(ptr, o, n) \
|
|
|
|
((__typeof__(*(ptr)))__cmpxchg_local((ptr), (unsigned long)(o), \
|
|
|
|
(unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))))
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_CMPXCHG64
|
2008-03-23 16:01:51 +08:00
|
|
|
#define cmpxchg64(ptr, o, n) \
|
|
|
|
((__typeof__(*(ptr)))__cmpxchg64((ptr), (unsigned long long)(o), \
|
|
|
|
(unsigned long long)(n)))
|
|
|
|
#define cmpxchg64_local(ptr, o, n) \
|
|
|
|
((__typeof__(*(ptr)))__cmpxchg64_local((ptr), (unsigned long long)(o), \
|
|
|
|
(unsigned long long)(n)))
|
2007-05-08 15:35:02 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
|
|
|
|
unsigned long new, int size)
|
|
|
|
{
|
|
|
|
unsigned long prev;
|
|
|
|
switch (size) {
|
|
|
|
case 1:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile(LOCK_PREFIX "cmpxchgb %b1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "q"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
case 2:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile(LOCK_PREFIX "cmpxchgw %w1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "r"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
case 4:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile(LOCK_PREFIX "cmpxchgl %1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "r"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Always use locked operations when touching memory shared with a
|
|
|
|
* hypervisor, since the system may be SMP even if the guest kernel
|
|
|
|
* isn't.
|
|
|
|
*/
|
|
|
|
static inline unsigned long __sync_cmpxchg(volatile void *ptr,
|
2008-03-23 16:01:51 +08:00
|
|
|
unsigned long old,
|
|
|
|
unsigned long new, int size)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
|
|
|
unsigned long prev;
|
|
|
|
switch (size) {
|
|
|
|
case 1:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("lock; cmpxchgb %b1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "q"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
case 2:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("lock; cmpxchgw %w1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "r"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
case 4:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("lock; cmpxchgl %1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "r"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long __cmpxchg_local(volatile void *ptr,
|
2008-03-23 16:01:51 +08:00
|
|
|
unsigned long old,
|
|
|
|
unsigned long new, int size)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
|
|
|
unsigned long prev;
|
|
|
|
switch (size) {
|
|
|
|
case 1:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("cmpxchgb %b1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "q"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
case 2:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("cmpxchgw %w1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "r"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
case 4:
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("cmpxchgl %1,%2"
|
|
|
|
: "=a"(prev)
|
|
|
|
: "r"(new), "m"(*__xg(ptr)), "0"(old)
|
|
|
|
: "memory");
|
2007-05-08 15:35:02 +08:00
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
static inline unsigned long long __cmpxchg64(volatile void *ptr,
|
2008-03-23 16:01:51 +08:00
|
|
|
unsigned long long old,
|
|
|
|
unsigned long long new)
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
{
|
|
|
|
unsigned long long prev;
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile(LOCK_PREFIX "cmpxchg8b %3"
|
|
|
|
: "=A"(prev)
|
|
|
|
: "b"((unsigned long)new),
|
|
|
|
"c"((unsigned long)(new >> 32)),
|
|
|
|
"m"(*__xg(ptr)),
|
|
|
|
"0"(old)
|
|
|
|
: "memory");
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long long __cmpxchg64_local(volatile void *ptr,
|
2008-03-23 16:01:51 +08:00
|
|
|
unsigned long long old,
|
|
|
|
unsigned long long new)
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
{
|
|
|
|
unsigned long long prev;
|
2008-03-23 16:01:51 +08:00
|
|
|
asm volatile("cmpxchg8b %3"
|
|
|
|
: "=A"(prev)
|
|
|
|
: "b"((unsigned long)new),
|
|
|
|
"c"((unsigned long)(new >> 32)),
|
|
|
|
"m"(*__xg(ptr)),
|
|
|
|
"0"(old)
|
|
|
|
: "memory");
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
return prev;
|
|
|
|
}
|
|
|
|
|
2007-05-08 15:35:02 +08:00
|
|
|
#ifndef CONFIG_X86_CMPXCHG
|
|
|
|
/*
|
|
|
|
* Building a kernel capable running on 80386. It may be necessary to
|
|
|
|
* simulate the cmpxchg on the 80386 CPU. For that purpose we define
|
|
|
|
* a function for each of the sizes we support.
|
|
|
|
*/
|
|
|
|
|
|
|
|
extern unsigned long cmpxchg_386_u8(volatile void *, u8, u8);
|
|
|
|
extern unsigned long cmpxchg_386_u16(volatile void *, u16, u16);
|
|
|
|
extern unsigned long cmpxchg_386_u32(volatile void *, u32, u32);
|
|
|
|
|
|
|
|
static inline unsigned long cmpxchg_386(volatile void *ptr, unsigned long old,
|
2008-03-23 16:01:51 +08:00
|
|
|
unsigned long new, int size)
|
2007-05-08 15:35:02 +08:00
|
|
|
{
|
|
|
|
switch (size) {
|
|
|
|
case 1:
|
|
|
|
return cmpxchg_386_u8(ptr, old, new);
|
|
|
|
case 2:
|
|
|
|
return cmpxchg_386_u16(ptr, old, new);
|
|
|
|
case 4:
|
|
|
|
return cmpxchg_386_u32(ptr, old, new);
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
#define cmpxchg(ptr, o, n) \
|
2007-05-08 15:35:02 +08:00
|
|
|
({ \
|
|
|
|
__typeof__(*(ptr)) __ret; \
|
|
|
|
if (likely(boot_cpu_data.x86 > 3)) \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))__cmpxchg((ptr), \
|
|
|
|
(unsigned long)(o), (unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))); \
|
2007-05-08 15:35:02 +08:00
|
|
|
else \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))cmpxchg_386((ptr), \
|
|
|
|
(unsigned long)(o), (unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))); \
|
2007-05-08 15:35:02 +08:00
|
|
|
__ret; \
|
|
|
|
})
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
#define cmpxchg_local(ptr, o, n) \
|
2007-05-08 15:35:02 +08:00
|
|
|
({ \
|
|
|
|
__typeof__(*(ptr)) __ret; \
|
|
|
|
if (likely(boot_cpu_data.x86 > 3)) \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))__cmpxchg_local((ptr), \
|
|
|
|
(unsigned long)(o), (unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))); \
|
2007-05-08 15:35:02 +08:00
|
|
|
else \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))cmpxchg_386((ptr), \
|
|
|
|
(unsigned long)(o), (unsigned long)(n), \
|
|
|
|
sizeof(*(ptr))); \
|
2007-05-08 15:35:02 +08:00
|
|
|
__ret; \
|
|
|
|
})
|
|
|
|
#endif
|
|
|
|
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
#ifndef CONFIG_X86_CMPXCHG64
|
|
|
|
/*
|
|
|
|
* Building a kernel capable running on 80386 and 80486. It may be necessary
|
|
|
|
* to simulate the cmpxchg8b on the 80386 and 80486 CPU.
|
|
|
|
*/
|
2007-05-08 15:35:02 +08:00
|
|
|
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
extern unsigned long long cmpxchg_486_u64(volatile void *, u64, u64);
|
|
|
|
|
|
|
|
#define cmpxchg64(ptr, o, n) \
|
|
|
|
({ \
|
|
|
|
__typeof__(*(ptr)) __ret; \
|
|
|
|
if (likely(boot_cpu_data.x86 > 4)) \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))__cmpxchg64((ptr), \
|
|
|
|
(unsigned long long)(o), \
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
(unsigned long long)(n)); \
|
|
|
|
else \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))cmpxchg_486_u64((ptr), \
|
|
|
|
(unsigned long long)(o), \
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
(unsigned long long)(n)); \
|
|
|
|
__ret; \
|
|
|
|
})
|
|
|
|
#define cmpxchg64_local(ptr, o, n) \
|
|
|
|
({ \
|
|
|
|
__typeof__(*(ptr)) __ret; \
|
|
|
|
if (likely(boot_cpu_data.x86 > 4)) \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))__cmpxchg64_local((ptr), \
|
|
|
|
(unsigned long long)(o), \
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
(unsigned long long)(n)); \
|
|
|
|
else \
|
2008-03-06 20:45:46 +08:00
|
|
|
__ret = (__typeof__(*(ptr)))cmpxchg_486_u64((ptr), \
|
|
|
|
(unsigned long long)(o), \
|
x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:30:47 +08:00
|
|
|
(unsigned long long)(n)); \
|
|
|
|
__ret; \
|
|
|
|
})
|
|
|
|
|
|
|
|
#endif
|
2007-05-08 15:35:02 +08:00
|
|
|
|
|
|
|
#endif
|