All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@intel.com>
To: Peter Zijlstra <peterz@infradead.org>, Andi Kleen <ak@linux.intel.com>
Cc: Stephane Eranian <eranian@google.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"acme@kernel.org" <acme@kernel.org>
Subject: RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters
Date: Tue, 23 Jan 2018 22:00:58 +0000	[thread overview]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07753803C1E@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <20180119213355.GE2269@hirez.programming.kicks-ass.net>

> On Fri, Jan 19, 2018 at 12:24:17PM -0800, Andi Kleen wrote:
> > > Oh, think a bit more.
> > > I think we cannot do the same thing as we did for CPU PMU's fixed
> counters.
> > >
> > > The counters here are free running counters. They cannot be start/stop.
> >
> > Yes free running counter have completely different semantics. They
> > need a separate event code.
> 
> The only thing that matters is if they count the same thing or not.
>

Hi Peter,

There is NO event available on the GPs, that is exactly the same as
the free-running counters.

For example, the BW free-running counters count the requests associated
with writes and completions.
The most similar events on the GPs are DATA_REQ_{OF,BY}_CPU.* events.
Except that some of their sub-events count requests which not completions.
There are also other minor differences.
So we don't have alternative events for the free-running counters.
I think we have to use 0xff.

For details, please refer to the uncore PMU guide. 
https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-uncore-performance-monitoring-manual.html

Thanks,
Kan
 
> The not start/stop thing is not important. See arch/x86/events/msr.c on how
> to deal with that. The short story is that you simply ignore stop and update
> the prev_count on start. Then any next update will increment with the
> correct delta.
> 
> (if the counter is short you also need to run a timer to deal with wraps).

  reply	other threads:[~2018-01-23 22:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 18:57 [PATCH V5 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore kan.liang
2018-01-15 18:57 ` [PATCH V5 2/8] perf/x86/intel/uncore: correct fixed counter index check for NHM kan.liang
2018-01-15 18:57 ` [PATCH V5 3/8] perf/x86/intel/uncore: correct fixed counter index check in generic code kan.liang
2018-01-15 18:57 ` [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters kan.liang
2018-01-18 13:32   ` Peter Zijlstra
2018-01-18 17:43     ` Liang, Kan
2018-01-19 13:07       ` Peter Zijlstra
2018-01-19 15:15         ` Liang, Kan
2018-01-19 17:19           ` Peter Zijlstra
2018-01-19 17:34             ` Stephane Eranian
2018-01-19 17:53             ` Liang, Kan
2018-01-19 17:55               ` Stephane Eranian
2018-01-19 18:00                 ` Liang, Kan
2018-01-19 20:18                   ` Stephane Eranian
2018-01-19 20:24                   ` Andi Kleen
2018-01-19 20:50                     ` Stephane Eranian
2018-01-19 20:51                       ` Stephane Eranian
2018-01-20  1:24                         ` Andi Kleen
2018-01-19 21:33                     ` Peter Zijlstra
2018-01-23 22:00                       ` Liang, Kan [this message]
2018-01-24 10:17                         ` Peter Zijlstra
2018-01-24 15:46                           ` Liang, Kan
2018-01-15 18:57 ` [PATCH V5 5/8] perf/x86/intel/uncore: add infrastructure for free running counter kan.liang
2018-01-15 18:57 ` [PATCH V5 6/8] perf/x86/intel/uncore: SKX support for IIO free running counters kan.liang
2018-01-15 18:57 ` [PATCH V5 7/8] perf/x86/intel/uncore: expose uncore_pmu_event functions kan.liang
2018-01-15 18:57 ` [PATCH V5 8/8] perf/x86/intel/uncore: clean up client IMC uncore kan.liang
2018-01-18  9:36 ` [PATCH V5 1/8] perf/x86/intel/uncore: customized event_read for " Thomas Gleixner

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=37D7C6CF3E00A74B8858931C1DB2F07753803C1E@SHSMSX103.ccr.corp.intel.com \
    --to=kan.liang@intel.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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.