All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yan, Zheng" <zheng.z.yan@intel.com>
To: Stephane Eranian <eranian@google.com>
Cc: a.p.zijlstra@chello.nl, mingo@elte.hu, andi@firstfloor.org,
	linux-kernel@vger.kernel.org, ming.m.lin@intel.com,
	Jiri Olsa <jolsa@redhat.com>
Subject: Re: [RFC PATCH V2 0/6] perf: Intel uncore pmu counting support
Date: Tue, 24 Apr 2012 16:56:21 +0800	[thread overview]
Message-ID: <4F966AB5.4010909@intel.com> (raw)
In-Reply-To: <CABPqkBQQo4TZVDA4pfujt7X0tTaV+PVOg8epDVS89DONV_XOtg@mail.gmail.com>

On 04/23/2012 11:21 PM, Stephane Eranian wrote:
> Hi,
> 
> [+jolsa as it may have something to do with the event parser]
> 
> I started testing this on my NHM desktop machine, and I ran into the following
> problem:
> $ perf stat -a -C 0 -e uncore_nhm/CLOCKTICKS/,cycles,ref-cycles  --
> taskset -c 0 noploop 1
> noploop for 1 seconds
>  Performance counter stats for 'taskset -c 0 noploop 1':
>      3,435,695,848 cycles                    #    0.000 GHz
>          [100.00%]
>      2,803,309,845 ref-cycles
>      2,410,926,590 pmu
>        1.001391268 seconds time elapsed
> 
> First here, the cmdline event order is not respected. uncore events
> appear at the end. That's not very
> intuitive. Especially when you know that they all show up as 'pmu'. In
> other words, you cannot figure
> out what each value represents.
> 
> $ sudo perf stat -a -C 0 -e uncore_nhm/CLOCKTICKS/  -- taskset -c 0 noploop 1
> noploop for 1 seconds
>  Performance counter stats for 'taskset -c 0 noploop 1':
>      2,410,862,301 pmu
>        1.001393218 seconds time elapsed
> 
> That looks like the right value, well, minus the 'pmu' event name. But
> that's a different problem.
> 
> But then, the pathological case:
> 
> $ sudo perf stat -a -C 0 -e
> uncore_nhm/CLOCKTICKS/,uncore_nhm/QMC_NORMAL_READS_ANY/  -- taskset -c
> 0 noploop 1
> noploop for 1 seconds
>  Performance counter stats for 'taskset -c 0 noploop 1':
>             10,705 pmu
>        1.001395772 seconds time elapsed
> 
> If you pass more than one uncore event, all but the last one are
> suppressed from the output.
> It does not happen with core PMU events.
> 
> Looks like something may be wrong in the way the parser adds uncore events.
> 
> 
Thank you very much for pointing out this. I will try changing the flex and
bison input files to generate reentrant parser. I hope it can solve all these
issues.

Regards
Yan, Zheng

> On Sun, Apr 1, 2012 at 3:41 AM, Yan, Zheng <zheng.z.yan@intel.com> wrote:
>> Hi, all
>>
>> Here is the RFC patches to add uncore counting support for Nehalem,
>> Sandy Bridge and Sandy Bridge-EP, applied on top of current tip.
>> The code is based on Lin Ming's old patches.
>>
>> For Nehalem and Sandy Bridge-EP, A few general events are exported
>> under directory:
>> /sys/bus/event_source/devices/uncore_xxx/events/
>>
>> You can use 'perf stat' to access to the uncore pmu. For example:
>> perf stat -a -C 0 -e 'uncore_nhm/QMC_WRITES_FULL_ANY/' sleep 1
>>
>> Any comment is appreciated.
>> Thank you
>>
>> ---
>> Changes since v1:
>>  - Modify perf tool to parse events from sysfs
>>  - A few minor code cleanup
>>


      reply	other threads:[~2012-04-24  8:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-01  1:41 [RFC PATCH V2 0/6] perf: Intel uncore pmu counting support Yan, Zheng
2012-04-01  1:41 ` [PATCH 1/6] perf: Export perf_assign_events Yan, Zheng
2012-04-01  1:41 ` [PATCH 2/6] perf: Generic intel uncore support Yan, Zheng
2012-04-01  1:41 ` [PATCH 3/6] perf: Add Nehalem and Sandy Bridge " Yan, Zheng
2012-04-01  1:41 ` [PATCH 4/6] perf tool: Parse general events from sysfs Yan, Zheng
2012-04-24  9:04   ` Jiri Olsa
2012-04-25  5:47     ` Yan, Zheng
2012-04-25 13:01       ` Jiri Olsa
2012-04-01  1:41 ` [PATCH 5/6] perf: Generic pci uncore device support Yan, Zheng
2012-04-01  1:41 ` [PATCH 6/6] perf: Add Sandy Bridge-EP uncore support Yan, Zheng
2012-04-23 15:21 ` [RFC PATCH V2 0/6] perf: Intel uncore pmu counting support Stephane Eranian
2012-04-24  8:56   ` Yan, Zheng [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=4F966AB5.4010909@intel.com \
    --to=zheng.z.yan@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --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 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.