[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E5586FD.7080103@goop.org>
Date: Wed, 24 Aug 2011 16:19:25 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "H. Peter Anvin" <hpa@...or.com>, Christoph Lameter <cl@...ux.com>,
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/24/2011 04:11 PM, Linus Torvalds wrote:
> On Wed, Aug 24, 2011 at 4:04 PM, H. Peter Anvin <hpa@...or.com> wrote:
>>> I was also thinking that using it reduces register pressure, since you
>>> don't need to keep the "old" value around, so it dies sooner.
>> ... but you burn a register for the intermediate flag value, so you're
>> just as bad off.
> But that register has much shorter liveness - so I do agree that it *can* help.
>
> Whether it actually *does* help is unclear. I do agree that we might
> be better off without introducing yet another (questionable)
> interface.
I think the interface is useful because it directly expresses what many
cmpxchg users want to know: "Did that work?" There are very few users
which actually care what the "old" value was if it wasn't what they were
expecting.
There's 3(ish) ways it could be implemented, but I don't have a strong
opinion on them:
1. with a direct compare, as people are doing now
2. with sete to set a flag (clearly better for > wordsize arguments)
3. with asm goto
4. (with a hypothetical gcc extension which exposes condition codes)
My experiments with asm goto were not very promising at first glance,
but it *should* be the best of the lot for most users. A hybrid 1/2
implementation would also be possible.
But the interface hides the implementation specifics, so its not all
that important.
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