All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>,
	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: Wed, 24 Jan 2018 15:46:49 +0000	[thread overview]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077538041CE@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <20180124101721.GQ2228@hirez.programming.kicks-ass.net>

> On Tue, Jan 23, 2018 at 10:00:58PM +0000, Liang, Kan wrote:
> > > 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.
> 
> OK, but explicitly mention this as the reason for having to invent event
> codes. Them being fixed purpose or free running isn't a valid reason for
> that.

Sure, I will add it in V6.

Thanks,
Kan

  reply	other threads:[~2018-01-24 15:47 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
2018-01-24 10:17                         ` Peter Zijlstra
2018-01-24 15:46                           ` Liang, Kan [this message]
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=37D7C6CF3E00A74B8858931C1DB2F077538041CE@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.