All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Ingo Molnar <mingo@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
	Andy Lutomirski <luto@amacapital.net>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [GIT PULL] perf x86 updates for v3.20
Date: Mon, 16 Feb 2015 12:55:25 -0800	[thread overview]
Message-ID: <54E2593D.1040007@amacapital.net> (raw)
In-Reply-To: <20150216074840.GA25445@gmail.com>

On 02/15/2015 11:48 PM, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest perf-core-for-linus git tree from:
>
>     git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus
>
>     # HEAD: a66734297f78707ce39d756b656bfae861d53f62 perf/x86: Add /sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks

[...]

> The extra CR4 manipulation adds ~ <50ns to the context
> switch cost between rdpmc-capable and rdpmc-non-capable
> mms.

That's about the best I could benchmark, too -- if it was more than 
about 50ns, I'm pretty sure I wouldn't seen a difference, but, as it 
stands, it seems to have been lost in the noise.  Maybe I should find a 
better benchmark.

In any event, this series is probably a mixed bag performance-wise.  In 
the best base, there's a small extra cost in context switches, and, when 
switching PCE, there's a CR4 write.  On SVM guests, the CR4 write will suck.

To balance that out, I removed a CR4 read from VMX entry and from global 
TLB flushes.  The former mostly fixes a performance regression from a 
security fix a few releases back, and the I expect that the latter will 
more than offset the added context switch overhead (especially on SVM 
guests, where even CR4 reads exit AFAIK).

Anyway, I tried and failed to detect any difference at all.  Context 
switch timing was very noisy for me.

--Andy

      reply	other threads:[~2015-02-16 20:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-16  7:48 [GIT PULL] perf x86 updates for v3.20 Ingo Molnar
2015-02-16 20:55 ` Andy Lutomirski [this message]

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=54E2593D.1040007@amacapital.net \
    --to=luto@amacapital.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.