From: Peter Zijlstra <peterz@infradead.org>
To: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: namhyung@kernel.org, eranian@google.com, acme@kernel.org,
mark.rutland@arm.com, jolsa@kernel.org, irogers@google.com,
bp@alien8.de, kan.liang@linux.intel.com, adrian.hunter@intel.com,
maddy@linux.ibm.com, x86@kernel.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
sandipan.das@amd.com, ananth.narayan@amd.com,
santosh.shukla@amd.com
Subject: Re: [PATCH v3 1/3] perf/core: Rework forwarding of {task|cpu}-clock events
Date: Tue, 2 May 2023 17:34:22 +0200 [thread overview]
Message-ID: <20230502153422.GE1597538@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230425142205.762-2-ravi.bangoria@amd.com>
On Tue, Apr 25, 2023 at 07:52:03PM +0530, Ravi Bangoria wrote:
> Currently, PERF_TYPE_SOFTWARE is treated specially since task-clock and
> cpu-clock events are interfaced through it but internally gets forwarded
> to their own pmus.
>
> Rework this by overwriting event->attr.type in perf_swevent_init() which
> will cause perf_init_event() to retry with updated type and event will
> automatically get forwarded to right pmu. With the change, SW pmu no
> longer needs to be treated specially and can be included in 'pmu_idr'
> list.
>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
> ---
> include/linux/perf_event.h | 11 ++++++
> kernel/events/core.c | 69 ++++++++++++++++++++------------------
> 2 files changed, 47 insertions(+), 33 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index d5628a7b5eaa..40647d707fb3 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -322,6 +322,9 @@ struct pmu {
> /* number of address filters this PMU can do */
> unsigned int nr_addr_filters;
>
> + /* Skip creating pmu device and sysfs interface. */
> + bool skip_sysfs_dev;
> +
> /*
> * Fully disable/enable this PMU, can be used to protect from the PMI
> * as well as for lazy/batch writing of the MSRs.
Does this make sense?
---
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -295,6 +295,8 @@ struct perf_event_pmu_context;
struct perf_output_handle;
+#define PMU_NULL_DEV ((void *)(~0))
+
/**
* struct pmu - generic performance monitoring unit
*/
@@ -322,9 +324,6 @@ struct pmu {
/* number of address filters this PMU can do */
unsigned int nr_addr_filters;
- /* Skip creating pmu device and sysfs interface. */
- bool skip_sysfs_dev;
-
/*
* Fully disable/enable this PMU, can be used to protect from the PMI
* as well as for lazy/batch writing of the MSRs.
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11113,7 +11113,7 @@ static struct pmu perf_cpu_clock = {
.task_ctx_nr = perf_sw_context,
.capabilities = PERF_PMU_CAP_NO_NMI,
- .skip_sysfs_dev = true,
+ .dev = PMU_NULL_DEV,
.event_init = cpu_clock_event_init,
.add = cpu_clock_event_add,
@@ -11195,7 +11195,7 @@ static struct pmu perf_task_clock = {
.task_ctx_nr = perf_sw_context,
.capabilities = PERF_PMU_CAP_NO_NMI,
- .skip_sysfs_dev = true,
+ .dev = PMU_NULL_DEV,
.event_init = task_clock_event_init,
.add = task_clock_event_add,
@@ -11442,7 +11442,7 @@ int perf_pmu_register(struct pmu *pmu, c
type = ret;
pmu->type = type;
- if (pmu_bus_running && !pmu->skip_sysfs_dev) {
+ if (pmu_bus_running && !pmu->dev) {
ret = pmu_dev_alloc(pmu);
if (ret)
goto free_idr;
@@ -11524,7 +11524,7 @@ void perf_pmu_unregister(struct pmu *pmu
free_percpu(pmu->pmu_disable_count);
idr_remove(&pmu_idr, pmu->type);
- if (pmu_bus_running) {
+ if (pmu_bus_running && pmu->dev != PMU_NULL_DEV) {
if (pmu->nr_addr_filters)
device_remove_file(pmu->dev, &dev_attr_nr_addr_filters);
device_del(pmu->dev);
@@ -13687,7 +13687,7 @@ static int __init perf_event_sysfs_init(
goto unlock;
list_for_each_entry(pmu, &pmus, entry) {
- if (pmu->skip_sysfs_dev)
+ if (pmu->dev)
continue;
ret = pmu_dev_alloc(pmu);
next prev parent reply other threads:[~2023-05-02 15:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-25 14:22 [PATCH v3 0/3] perf: Rework event forwarding logic Ravi Bangoria
2023-04-25 14:22 ` [PATCH v3 1/3] perf/core: Rework forwarding of {task|cpu}-clock events Ravi Bangoria
2023-05-02 15:34 ` Peter Zijlstra [this message]
2023-05-03 8:32 ` Ravi Bangoria
2023-04-25 14:22 ` [PATCH v3 2/3] perf/ibs: Fix interface via core pmu events Ravi Bangoria
2023-05-02 15:37 ` Peter Zijlstra
2023-05-03 8:33 ` Ravi Bangoria
2023-04-25 14:22 ` [PATCH v3 3/3] perf test: Add selftest to test IBS invocation " Ravi Bangoria
2023-04-29 21:09 ` Ian Rogers
2023-05-02 3:08 ` Ravi Bangoria
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=20230502153422.GE1597538@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ananth.narayan@amd.com \
--cc=bp@alien8.de \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mark.rutland@arm.com \
--cc=namhyung@kernel.org \
--cc=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=santosh.shukla@amd.com \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®