* How does spin_unlock() in x86-64 align with the description in Documention/memory-barriers.txt?
@ 2013-03-22 11:58 Zhu Yanhai
2013-03-22 12:15 ` Jan Beulich
0 siblings, 1 reply; 2+ messages in thread
From: Zhu Yanhai @ 2013-03-22 11:58 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Richard Weinberger,
Jan Beulich, Andrew Morton
Cc: LKML, x86, muming.wq
Hi all,
In the documention it reads,
(2) UNLOCK operation implication:
Memory operations issued before the UNLOCK will be completed before the
UNLOCK operation has completed.
Memory operations issued after the UNLOCK may be completed before the
UNLOCK operation has completed.
However, on x86-64 __ticket_spin_unlock() merely does,
static __always_inline void __ticket_spin_unlock(raw_spinlock_t *lock)
{
asm volatile(
ALTERNATIVE(UNLOCK_LOCK_PREFIX"incb (%0);"ASM_NOP3,
UNLOCK_LOCK_ALT_PREFIX"movw $0, (%0)",
X86_FEATURE_UNFAIR_SPINLOCK)
:
: "Q" (&lock->slock)
: "memory", "cc");
}
While both UNLOCK_LOCK_PREFIX and UNLOCK_LOCK_ALT_PREFIX are empty
strings. So how such a function keeps the memory operations issued
before it completed?
--
Thanks,
Zhu Yanhai
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: How does spin_unlock() in x86-64 align with the description in Documention/memory-barriers.txt?
2013-03-22 11:58 How does spin_unlock() in x86-64 align with the description in Documention/memory-barriers.txt? Zhu Yanhai
@ 2013-03-22 12:15 ` Jan Beulich
0 siblings, 0 replies; 2+ messages in thread
From: Jan Beulich @ 2013-03-22 12:15 UTC (permalink / raw)
To: Zhu Yanhai
Cc: x86, Thomas Gleixner, Andrew Morton, Richard Weinberger,
Ingo Molnar, muming.wq, LKML, H. Peter Anvin
>>> On 22.03.13 at 12:58, Zhu Yanhai <zhu.yanhai@gmail.com> wrote:
> Hi all,
> In the documention it reads,
>
> (2) UNLOCK operation implication:
>
> Memory operations issued before the UNLOCK will be completed before the
> UNLOCK operation has completed.
>
> Memory operations issued after the UNLOCK may be completed before the
> UNLOCK operation has completed.
>
> However, on x86-64 __ticket_spin_unlock() merely does,
>
> static __always_inline void __ticket_spin_unlock(raw_spinlock_t *lock)
> {
> asm volatile(
> ALTERNATIVE(UNLOCK_LOCK_PREFIX"incb (%0);"ASM_NOP3,
> UNLOCK_LOCK_ALT_PREFIX"movw $0, (%0)",
> X86_FEATURE_UNFAIR_SPINLOCK)
> :
> : "Q" (&lock->slock)
> : "memory", "cc");
> }
>
> While both UNLOCK_LOCK_PREFIX and UNLOCK_LOCK_ALT_PREFIX are empty
> strings. So how such a function keeps the memory operations issued
> before it completed?
Please read the section "Memory Ordering in P6 and More Recent
Processor Families" in SDM Vol 3.
Jan
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-03-22 12:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-22 11:58 How does spin_unlock() in x86-64 align with the description in Documention/memory-barriers.txt? Zhu Yanhai
2013-03-22 12:15 ` Jan Beulich
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®