From: Michael Breuer <mbreuer@majjas.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Mike Galbraith <efault@gmx.de>,
Arjan van de Ven <arjan@infradead.org>,
Joerg Roedel <joro@8bytes.org>
Subject: Re: x86 - cpu_relax - why nop vs. pause?
Date: Sun, 07 Feb 2010 22:50:26 -0500 [thread overview]
Message-ID: <4B6F8A02.2060006@majjas.com> (raw)
In-Reply-To: <4B6F2D59.1070508@majjas.com>
On 2/7/2010 4:15 PM, Michael Breuer wrote:
> On 02/07/2010 03:08 PM, Michael Breuer wrote:
>> On 2/7/2010 1:14 PM, Mike Galbraith wrote:
>> ...
>> Case1 - asm volatile("pause" ::: "memory");
>> 0000000000400480 <main>:
>> 400480: f3 90 pause
>> 400482: c3 retq
>> 400483: 90 nop
>>
>> ...
>>
>> Case3 - asm volitile("rep;pause" ::: "memory")
>> 0000000000400480 <main>:
>> 400480: f3 f3 90 pause
>> 400483: c3 retq
>> 400484: 90 nop
>> _______
>> Note the difference between opcodes case 1 and case 3, and the mess
>> made by the compiler in case 2.
>>
>> As to benchmarks - I've checked a few things, no formal or lasting
>> stuff... but striking at first glance:
>>
>> 1) At idle, perf top shows time spent in _raw_spin_lock dropping from
>> ~35% to ~25%.
>> 2) Running a media transcode (single core - handbrakecli): frame rate
>> increased by about 5-10%.
>> 3) During file-intensive operations (#2, above, or copying large
>> files - ext4 on software raid6) - latencytop shows a decerase on
>> writing a page to disc from about 120ms to about 90ms.
>>
> Disregard case 2 - was missing -O3. With -O3 or -O2 rep;nop and pause
> are identical. The interesting case is rep;pause which is different
> and seems more efficient.
Just to move away from this... totally perplexed, I retested a bit.
Seems something else had gone wrong causing me to try 'rep;pause' vs.
'pause'. The resulting opcode is f3 f3 90, as noted above.
I do see what seems to be a small but noticeable performance improvement
- no idea if there's a downside, and also no idea what f3 f3 90 does vs.
f3 90. Might be something interesting, or maybe not.
Test scenario:
Boot clean to single user mode. perform tiotest -8 five times.
%cpu is %usr + %sys as reported by tiotest.
Results:
Writes
pause: 1.14 sec; 72.01MB/sec; 322.44%cpu
rep;pause: 1.12 sec; 70.4MB/sec; 311.58%cpu
Random Writes
pause: 3.7 sec; 8.51MB/sec; 66.48%cpu
rep;pause 3.46sec; 9.04MB/sec; 72.34%cpu
Reads
pause: 11557.48MB/sec; 6040.74%cpu
rep;pause 11620.15MB/sec; 5974.90%cpu
Random Reads
pause: 11416.9MB/sec; 5330.50%cpu
rep;pause 11786.99MB/sec; 5118.66%cpu
next prev parent reply other threads:[~2010-02-08 3:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-07 17:28 x86 - cpu_relax - why nop vs. pause? Michael Breuer
2010-02-07 18:09 ` Joerg Roedel
2010-02-07 18:32 ` Arjan van de Ven
[not found] ` <1265566470.6280.10.camel@marge.simson.net>
2010-02-07 20:08 ` Michael Breuer
2010-02-07 21:15 ` Michael Breuer
2010-02-08 3:50 ` Michael Breuer [this message]
2010-02-08 13:33 ` Artur Skawina
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=4B6F8A02.2060006@majjas.com \
--to=mbreuer@majjas.com \
--cc=arjan@infradead.org \
--cc=efault@gmx.de \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.