From: Stephane Eranian <eranian@google.com>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"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>,
"ak@linux.intel.com" <ak@linux.intel.com>
Subject: Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters
Date: Fri, 19 Jan 2018 09:55:11 -0800 [thread overview]
Message-ID: <CABPqkBRb5s-RH+bDNebbxDgVFwSNanmo3Q7hEnMB4JQiW4d77A@mail.gmail.com> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077538026F3@SHSMSX103.ccr.corp.intel.com>
On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan <kan.liang@intel.com> wrote:
>> On Fri, Jan 19, 2018 at 03:15:00PM +0000, Liang, Kan wrote:
>> > >
>> > > On Thu, Jan 18, 2018 at 05:43:10PM +0000, Liang, Kan wrote:
>> > > > In the uncore document, there is no event-code assigned to free
>> > > > running
>> > > counters.
>> > > > Some events need to be defined to indicate the free running counters.
>> > > > The events are encoded as event-code + umask-code.
>> > > >
>> > > > The event-code for all free running counters is 0xff, which is the
>> > > > same as the fixed counters.
>> > >
>> > > Is it possible to count the same things using the generic counters?
>> > >
>> >
>> > Yes, there are events for generic counters to count bandwidth and
>> > utilization.
>> >
>> > The reasons of introducing free running counters are
>> > - To provide highly valuable information (bandwidth and utilization)
>> > which most of the customers are interested in
>> > - To save on the precious generic counters
>>
>> _IF_ the exact same counters are available on the GPs then we must use the
>> same event code for them and use event scheduling to place them on
>> fixed/free-running counters when possible.
>
> OK. I will check if there are the exact same events on GPs for
> those free running counters.
>
You can measure the bandwidth and utilization on the GP. I am doing it all
the time.
> Thanks,
> Kan
>
>>
>> That's what we do for the CPU PMU's fixed counters too.
>>
>> Don't invent magic event codes just because.
next prev parent reply other threads:[~2018-01-19 17:55 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 [this message]
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
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=CABPqkBRb5s-RH+bDNebbxDgVFwSNanmo3Q7hEnMB4JQiW4d77A@mail.gmail.com \
--to=eranian@google.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=kan.liang@intel.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.