[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1108241408310.30776@router.home>
Date: Wed, 24 Aug 2011 14:27:55 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
cc: "H. Peter Anvin" <hpa@...or.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 Wed, 24 Aug 2011, Jeremy Fitzhardinge wrote:
> I only looked in arch/x86, but I didn't find any that were
> straightforward candidates for cmpxchg_flag.
Look at core code: mm/slub.c
> > And if the cmpxchg is a 16 byte
> > cmpxchg (cmpxchg_double) then the comparison is getting more expensive.
>
> We're talking about the difference between cmpxchg_flag() - which does
> a sete based on the flags set up cmpxchg - and a variant based on "asm
> goto" which could, in principle, avoid the need for sete by allowing a
> control flow statment to directly use the asm goto's conditional jump.
> The performance of both is invariant wrt the cmpxchg argument size.
Indeed for sete the size of the argument does not matter. Look at
percpu_cmpxchg_double() and cmpxchg_double() in arch/x86/include for some
of the functions I wrote. The sete is used to avoid the double word
comparisons that would otherwise have been necessary.
But still the solution with the flags would save another instruction and
the generated code would not be as ugly. For not only do you have an
additional sete you will then also have to check the result again. This
means at least two additional instruction.
--
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