All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jin Yao <yao.jin@linux.intel.com>
Cc: jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com,
	alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org,
	ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com
Subject: Re: [PATCH] perf stat: Skip duration_time in setup_system_wide
Date: Tue, 22 Sep 2020 15:02:18 -0300	[thread overview]
Message-ID: <20200922180218.GC2248446@kernel.org> (raw)
In-Reply-To: <20200922175630.GB2248446@kernel.org>

Em Tue, Sep 22, 2020 at 02:56:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Sep 22, 2020 at 09:50:04AM +0800, Jin Yao escreveu:
> > Some metrics (such as DRAM_BW_Use) consists of uncore events and
> > duration_time. For uncore events, counter->core.system_wide is
> > true. But for duration_time, counter->core.system_wide is false
> > so target.system_wide is set to false.
> > 
> > Then 'enable_on_exec' is set in perf_event_attr of uncore event.
> > Kernel will return error when trying to open the uncore event.
> > 
> > This patch skips the duration_time in setup_system_wide then
> > target.system_wide will be set to true for the evlist of uncore
> > events + duration_time.
> > 
> > Before (tested on skylake desktop):
> > 
> >  # perf stat -M DRAM_BW_Use -- sleep 1
> >  Error:
> >  The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (arb/event=0x84,umask=0x1/).
> >  /bin/dmesg | grep -i perf may provide additional information.
> > 
> > After:
> > 
> >  # perf stat -M DRAM_BW_Use -- sleep 1
> > 
> >   Performance counter stats for 'system wide':
> > 
> >                 169      arb/event=0x84,umask=0x1/ #     0.00 DRAM_BW_Use
> >              40,427      arb/event=0x81,umask=0x1/
> >       1,000,902,197 ns   duration_time
> > 
> >         1.000902197 seconds time elapsed
> > 
> > Fixes: 648b5af3f3ae ("libperf: Move 'system_wide' from 'struct evsel' to 'struct perf_evsel'")
> 
> Humm, what makes you think that this cset was the one introducing this
> problem? It just moves evsel->system_wide to evsel->core.system_wide.

Apart from that I reproduced the problem and after applying your patch
it seems cured:

  [acme@quaco perf]$ grep 'model name' -m1 /proc/cpuinfo
  model name	: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz

Before (with -v to see details):

  [root@quaco ~]# perf stat -v -M DRAM_BW_Use -- sleep 1
  Using CPUID GenuineIntel-6-8E-A
  metric expr 64 * ( arb@event\=0x81\,umask\=0x1@ + arb@event\=0x84\,umask\=0x1@ ) / 1000000 / duration_time / 1000 for DRAM_BW_Use
  found event duration_time
  found event arb/event=0x84,umask=0x1/
  found event arb/event=0x81,umask=0x1/
  adding {arb/event=0x84,umask=0x1/,arb/event=0x81,umask=0x1/}:W,duration_time
  Control descriptor is not initialized
  Warning:
  arb/event=0x84,umask=0x1/ event is not supported by the kernel.
  Error:
  The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (arb/event=0x84,umask=0x1/).
  /bin/dmesg | grep -i perf may provide additional information.
  
  [root@quaco ~]#

After:

  [root@quaco ~]# perf stat -M DRAM_BW_Use -- sleep 1
  
   Performance counter stats for 'system wide':
  
               2,806      arb/event=0x84,umask=0x1/ #     0.63 DRAM_BW_Use
          10,001,820      arb/event=0x81,umask=0x1/
       1,016,875,686 ns   duration_time
  
         1.016875686 seconds time elapsed
  
  [root@quaco ~]#

So I'm removing that fixes and adding this one, that I think is where
"duration_time" was being considered...

Fixes: e3ba76deef23064f ("perf tools: Force uncore events to system wide monitoring")

Also, wouldn't it be better to have the duration_time event with its
evsel->core.system_wide set to true?

- Arnaldo

  reply	other threads:[~2020-09-22 18:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  1:50 [PATCH] perf stat: Skip duration_time in setup_system_wide Jin Yao
2020-09-22 17:56 ` Arnaldo Carvalho de Melo
2020-09-22 18:02   ` Arnaldo Carvalho de Melo [this message]
2020-09-23  2:05     ` Jin, Yao

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=20200922180218.GC2248446@kernel.org \
    --to=acme@kernel.org \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@intel.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=yao.jin@intel.com \
    --cc=yao.jin@linux.intel.com \
    /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.