[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E542681.2090703@goop.org>
Date: Tue, 23 Aug 2011 15:15:29 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: "H. Peter Anvin" <hpa@...or.com>
CC: Christoph Lameter <cl@...ux.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Nick Piggin <npiggin@...nel.dk>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Subject: Re: [PATCH 13/15] x86: add cmpxchg_flag() variant
On 08/23/2011 01:45 PM, H. Peter Anvin wrote:
> On 08/23/2011 12:53 PM, Jeremy Fitzhardinge wrote:
>> Yes, that would ideal. The closest you can get is asm goto(), but the
>> syntax for that would be awful; something like:
>>
>> #define cmpxchg_jump(ptr, old, new, fail)\
>> asm goto (...)
>>
>>
>> :
>> :
>>
>> again:
>> old = *thingp;
>> new = frobulate(old);
>> cmpxchg_jump(thingp, old, new, again);
>> /* worked */
>>
>> Would this be useful enough?
>>
> Actually there is a trick:
>
> static inline bool ....
> {
> asm goto(... yes);
> no:
> return false;
> yes:
> return true;
> }
>
> ... which makes syntax a heckuva lot less awkward.
Yeah, but you'd need to define an inline for each type, since the
function isn't polymorphic. But it can be done with a macro.
However, having prototyped it, I dunno, it doesn't really seem like much
of a win for all the extra code it adds. I just can't get too excited
about an extra test instruction adjacent to a monster like a locked
cmpxchg. The jump variant avoids the test, but gcc still generates some
pretty bogus stuff:
lock; cmpxchgq %rbx,(%rcx); jne .L88 # D.24853, MEM[(volatile u64 *)top_p_26],
# 0 "" 2
#NO_APP
jmp .L87 #
.L88:
xorl %esi, %esi #
movq %rbx, %rdi # D.24853,
call free_pages #
.L87:
addq p2m_top_mfn(%rip), %r13 # p2m_top_mfn, D.24896
movq p2m_top_mfn_p(%rip), %rax # p2m_top_mfn_p, p2m_top_mfn_p
and adding unlikely()s doesn't help at all.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists