All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jin, Yao" <yao.jin@linux.intel.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
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: Wed, 23 Sep 2020 10:05:56 +0800	[thread overview]
Message-ID: <8b4e9938-2d15-8320-85e9-e14ddd51c743@linux.intel.com> (raw)
In-Reply-To: <20200922180218.GC2248446@kernel.org>

Hi Arnaldo,

On 9/23/2020 2:02 AM, Arnaldo Carvalho de Melo wrote:
> 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")
> 

Yes, this fixes is much better, thanks.

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

That looks to be another solution, should be OK too I think. :)

But anyway we need a test.

Thanks
Jin Yao

> - Arnaldo
> 

      reply	other threads:[~2020-09-23  2:06 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
2020-09-23  2:05     ` Jin, Yao [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=8b4e9938-2d15-8320-85e9-e14ddd51c743@linux.intel.com \
    --to=yao.jin@linux.intel.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=acme@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 \
    /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.