public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, ak@linux.intel.com,
	jmario@redhat.com, dzickus@redhat.com, jolsa@redhat.com,
	acme@redhat.com
Subject: Re: [PATCH 2/2] perf/x86: fix constraints for load latency and precise events
Date: Mon, 23 Jun 2014 10:42:54 +0200	[thread overview]
Message-ID: <20140623084254.GK19860@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <1403193509-22393-3-git-send-email-eranian@google.com>

On Thu, Jun 19, 2014 at 05:58:29PM +0200, Stephane Eranian wrote:
> The load latency does not have to be constrained to counter 3
> on any of SNB, IVB, HSW. It operates fine on any PEBS-capable
> counter.
> 
> The precise store event for SNB, IVB needs to be on counter 3.
> But on Haswell, precise store is implemented differently and
> the constraint is not needed anymore, so we remove it.
> 
> The artificial constraint on counter 3 was used to ease
> scheduling because the load latency events rely on an
> extra MSR which is shared for all the counters. But
> perf_events has an infrastructure to handle shared_regs
> and does not need to constrain the load latency event to
> a single counter. It was already using that infrastructure
> with the constraint on counter 3. By eliminating the constraint
> on load latency, it becomes possible to measure loads and stores
> precisely without multiplexing.

So that all makes sense, except why did they pick the same constraint to
begin with? If they'd picked cnt2 for ll and cnt3 (as per the hardware
constraint) for st, this would've already been possible right?

Except of course, that the SDM states that no other PEBS event should be
active when using ll; we don't enforce that (although userspace could
request exclusive). What about this constraint? Is the SDM wrong about
this?

  parent reply	other threads:[~2014-06-23  8:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 15:58 [PATCH 0/2] perf/x86: improve Intel load latency and precise store event constraints Stephane Eranian
2014-06-19 15:58 ` [PATCH 1/2] perf/x86: update Haswell PEBS " Stephane Eranian
2014-06-19 18:00   ` Andi Kleen
2014-06-19 19:53     ` Stephane Eranian
2014-06-19 20:18       ` Andi Kleen
2014-06-19 20:31         ` Stephane Eranian
2014-06-19 20:40           ` Andi Kleen
2014-06-19 20:45             ` Stephane Eranian
2014-06-20 13:44               ` Stephane Eranian
2014-06-23  7:35             ` Peter Zijlstra
2014-06-23 14:16               ` Andi Kleen
2014-06-23  7:14     ` Peter Zijlstra
2014-06-23  8:06       ` Stephane Eranian
2014-06-23 11:37         ` Peter Zijlstra
2014-06-23 11:51           ` Stephane Eranian
2014-06-23 15:47           ` Andi Kleen
2014-06-23  7:12   ` Peter Zijlstra
2014-06-19 15:58 ` [PATCH 2/2] perf/x86: fix constraints for load latency and precise events Stephane Eranian
2014-06-19 20:56   ` Andi Kleen
2014-06-23  8:42   ` Peter Zijlstra [this message]
2014-06-23  9:00     ` Stephane Eranian
2014-06-23 11:39       ` Peter Zijlstra
2014-06-23 14:22       ` Andi Kleen

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=20140623084254.GK19860@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=dzickus@redhat.com \
    --cc=eranian@google.com \
    --cc=jmario@redhat.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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