public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zamsden@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH] x86 rwsem optimization extreme
Date: Wed, 17 Feb 2010 15:03:52 -1000	[thread overview]
Message-ID: <4B7C91F8.50509@redhat.com> (raw)
In-Reply-To: <4B7C7BE4.9050908@zytor.com>

>
> On 02/17/2010 02:10 PM, Linus Torvalds wrote:
>    
>> The cost of 'adc' may happen to be identical in this case, but I suspect
>> you didn't test on UP, where the 'lock' prefix goes away. An unlocked
>> 'add' tends to be faster than an unlocked 'adc'.
>>
>> (It's possible that some micro-architectures don't care, since it's a
>> memory op, and they can see that 'C' is set. But it's a fragile assumption
>> that it would always be ok).
>>
>>      
> FWIW, I don't know of any microarchitecture where adc is slower than
> add, *as long as* the setup time for the CF flag is already used up.
> However, as I already commented, I don't think this is worth it.  This
> inline appears to only be instantiated once, and as such, it takes a
> whopping six bytes across the entire kernel.
>
>    

Without the locks,

stc; adc %rdx, (%rax)

vs.

add %rdx, (%rax)

Shows no statistical difference on Intel.
On AMD, the first form is about twice as expensive.

Course this is all completely useless, but it would be if the locks were 
inline (which is actually an askable question now).  There was just so 
much awesomeness going on with the 64-bit rwsem constructs I felt I had 
to add even more awesomeness to the plate.  For some definition of 
awesomeness.

Zach

  reply	other threads:[~2010-02-18  1:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-17 21:58 [PATCH] x86 rwsem optimization extreme Zachary Amsden
2010-02-17 22:10 ` Linus Torvalds
2010-02-17 22:29   ` H. Peter Anvin
2010-02-17 23:29   ` H. Peter Anvin
2010-02-18  1:03     ` Zachary Amsden [this message]
2010-02-18  1:53     ` Linus Torvalds
2010-02-18  1:59       ` H. Peter Anvin
2010-02-18  4:25         ` Zachary Amsden
2010-02-18  8:12           ` Andi Kleen
2010-02-18  8:24             ` Zachary Amsden
2010-02-18  9:29               ` Andi Kleen
2010-02-18 10:55               ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B7C91F8.50509@redhat.com \
    --to=zamsden@redhat.com \
    --cc=avi@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox