From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Florian Fischer <florian.fischer@muhq.space>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] perf stat: Introduce skippable evsels
Date: Thu, 13 Apr 2023 09:15:05 -0400 [thread overview]
Message-ID: <2a6f6cf3-3de1-33e4-3b51-8c702c270bda@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fUELu6nT8sGjkPvzKOX2qxH-w9q5mJgsjLBoYwAQ5bP6Q@mail.gmail.com>
On 2023-04-12 2:01 p.m., Ian Rogers wrote:
>> - We shouldn't only rely on the event list file. We need to do runtime
>> check on the availability of events. Either perf_event_open() or
>> /sys/devices/cpu/events/ is fine (althourh personally I prefer sys way,
>> since I think it's easier).
> Using perf_event_open is the status quo and the sysfs approach is
> impractical imo. I think the only thing that is needed in v2 is for
> <not counted> to be displayed for skippable evsels.
Using perf_event_open is good to check features. If the feature is not
supported by the kernel, it will be explicitly rejected.
But I'm not sure about the availability of events. The kernel doesn't
check every events. For example, on ICL and later platform, we have
event=0x00,umask=0x8X for all the topdown metrics events. If we open
them on SKL, the perf_event_open will also success, but return 0 value.
Thanks,
Kan
next prev parent reply other threads:[~2023-04-13 13:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 20:56 [PATCH v1] perf stat: Introduce skippable evsels Ian Rogers
2023-04-12 13:44 ` Liang, Kan
2023-04-12 16:04 ` Ian Rogers
2023-04-12 17:32 ` Liang, Kan
2023-04-12 18:01 ` Ian Rogers
2023-04-13 13:15 ` Liang, Kan [this message]
2023-04-13 13:52 ` Ian Rogers
2023-04-13 14:36 ` Liang, Kan
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=2a6f6cf3-3de1-33e4-3b51-8c702c270bda@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=florian.fischer@muhq.space \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).