mbox series

[00/10] perf/core: Generalise event exclusion checking

Message ID 1542363853-13849-1-git-send-email-andrew.murray@arm.com
Headers show
Series perf/core: Generalise event exclusion checking | expand

Message

Andrew Murray Nov. 16, 2018, 10:24 a.m. UTC
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags.

However this approach requires that each time a new event modifier is
added to perf, all the perf drivers need to be modified to indicate that
they don't support the attribute. This results in additional boiler-plate
code common to many drivers that needs to be maintained. An example of
this is the addition of exclude_host and exclude_guest in 2011 yet many
PMU drivers do not support this or indicate an error on events that make
use of it.

This patch generalises the test for exclusion and updates PMU drivers to
use it. This is a functional change as some PMU drivers will now correctly
report that they don't support certain events whereas they previously did.

An alternative approach might have been to provide a static perf_event_attr
with exclusion events set such that each PMU driver could compare against
(see ref [1]) - however this is less readable. A longer term approach may
instead be for PMU's to advertise their capabilities on registration.

All drivers touched by this patchset have been compile tested.

[1] https://lore.kernel.org/patchwork/patch/325116/
~                                                               

Andrew Murray (10):
  perf/core: Add macro to test for event exclusion flags
  arm: perf/core: generalise event exclusion checking with perf macro
  arm: perf: add additional validation to set_event_filter
  powerpc: perf/core: generalise event exclusion checking with perf
    macro
  powerpc/pmu/fsl: add additional validation to event_init
  alpha: perf/core: generalise event exclusion checking with perf macro
  x86: perf/core: generalise event exclusion checking with perf macro
  perf/core: Remove unused perf_flags
  drivers/perf: perf/core: generalise event exclusion checking with perf
    macro
  perf/doc: update design.txt for exclude_{host|guest} flags

 arch/alpha/kernel/perf_event.c           |  4 +---
 arch/arm/kernel/perf_event_v7.c          |  2 ++
 arch/arm/mach-imx/mmdc.c                 |  8 +-------
 arch/arm/mm/cache-l2x0-pmu.c             |  7 +------
 arch/powerpc/perf/core-fsl-emb.c         |  2 ++
 arch/powerpc/perf/hv-24x7.c              |  7 +------
 arch/powerpc/perf/hv-gpci.c              |  7 +------
 arch/powerpc/perf/imc-pmu.c              | 14 ++------------
 arch/x86/events/amd/ibs.c                | 11 +----------
 arch/x86/events/amd/iommu.c              |  3 +--
 arch/x86/events/amd/power.c              |  8 +-------
 arch/x86/events/amd/uncore.c             |  3 +--
 arch/x86/events/intel/cstate.c           |  7 +------
 arch/x86/events/intel/rapl.c             |  7 +------
 arch/x86/events/intel/uncore.c           |  3 +--
 arch/x86/events/intel/uncore_snb.c       |  7 +------
 arch/x86/events/msr.c                    |  7 +------
 drivers/perf/arm-cci.c                   |  7 +------
 drivers/perf/arm-ccn.c                   |  5 +----
 drivers/perf/arm_dsu_pmu.c               |  7 +------
 drivers/perf/arm_pmu.c                   |  9 +--------
 drivers/perf/hisilicon/hisi_uncore_pmu.c |  7 +------
 drivers/perf/qcom_l2_pmu.c               |  3 +--
 drivers/perf/qcom_l3_pmu.c               |  3 +--
 drivers/perf/xgene_pmu.c                 |  3 +--
 include/linux/perf_event.h               |  9 +++++++++
 include/uapi/linux/perf_event.h          |  2 --
 tools/include/uapi/linux/perf_event.h    |  2 --
 tools/perf/design.txt                    |  4 ++++
 29 files changed, 41 insertions(+), 127 deletions(-)

Comments

Peter Zijlstra Nov. 19, 2018, 1:08 p.m. UTC | #1
On Fri, Nov 16, 2018 at 10:24:03AM +0000, Andrew Murray wrote:
> Many PMU drivers do not have the capability to exclude counting events
> that occur in specific contexts such as idle, kernel, guest, etc. These
> drivers indicate this by returning an error in their event_init upon
> testing the events attribute flags.
> 
> However this approach requires that each time a new event modifier is
> added to perf, all the perf drivers need to be modified to indicate that
> they don't support the attribute. This results in additional boiler-plate
> code common to many drivers that needs to be maintained. An example of
> this is the addition of exclude_host and exclude_guest in 2011 yet many
> PMU drivers do not support this or indicate an error on events that make
> use of it.
> 
> This patch generalises the test for exclusion and updates PMU drivers to
> use it. This is a functional change as some PMU drivers will now correctly
> report that they don't support certain events whereas they previously did.

Right, I like that idea, and yes, there's a lot of fail around there :/

> A longer term approach may instead be for PMU's to advertise their
> capabilities on registration.

This I think is the better approach. We already have the
PERF_PMU_CAP_flags that can be used to advertise various PMU
capabilities.

Something along these lines I suppose; then every PMU that actually
checks the flags, needs to set the flag, otherwise it'll fail.

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 53c500f0ca79..de15723ea52a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -244,6 +244,7 @@ struct perf_event;
 #define PERF_PMU_CAP_EXCLUSIVE			0x10
 #define PERF_PMU_CAP_ITRACE			0x20
 #define PERF_PMU_CAP_HETEROGENEOUS_CPUS		0x40
+#define PERF_PMU_CAP_EXCLUDE			0x80
 
 /**
  * struct pmu - generic performance monitoring unit
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 84530ab358c3..d76b724177b9 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -9772,6 +9772,14 @@ static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
 	if (ctx)
 		perf_event_ctx_unlock(event->group_leader, ctx);
 
+	if (!ret) {
+		if ((pmu->capabilities & PERF_PMU_CAP_EXCLUDE) ||
+		    event_has_exclude_flags(event)) {
+			event->destroy(event);
+			ret = -EINVAL;
+		}
+	}
+
 	if (ret)
 		module_put(pmu->module);
Andrew Murray Nov. 22, 2018, 12:21 p.m. UTC | #2
On Mon, Nov 19, 2018 at 02:08:00PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 16, 2018 at 10:24:03AM +0000, Andrew Murray wrote:
> > Many PMU drivers do not have the capability to exclude counting events
> > that occur in specific contexts such as idle, kernel, guest, etc. These
> > drivers indicate this by returning an error in their event_init upon
> > testing the events attribute flags.
> > 
> > However this approach requires that each time a new event modifier is
> > added to perf, all the perf drivers need to be modified to indicate that
> > they don't support the attribute. This results in additional boiler-plate
> > code common to many drivers that needs to be maintained. An example of
> > this is the addition of exclude_host and exclude_guest in 2011 yet many
> > PMU drivers do not support this or indicate an error on events that make
> > use of it.
> > 
> > This patch generalises the test for exclusion and updates PMU drivers to
> > use it. This is a functional change as some PMU drivers will now correctly
> > report that they don't support certain events whereas they previously did.
> 
> Right, I like that idea, and yes, there's a lot of fail around there :/
> 
> > A longer term approach may instead be for PMU's to advertise their
> > capabilities on registration.
> 
> This I think is the better approach. We already have the
> PERF_PMU_CAP_flags that can be used to advertise various PMU
> capabilities.

OK I'll respin my series to take this approach.

> 
> Something along these lines I suppose; then every PMU that actually
> checks the flags, needs to set the flag, otherwise it'll fail.
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 53c500f0ca79..de15723ea52a 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -244,6 +244,7 @@ struct perf_event;
>  #define PERF_PMU_CAP_EXCLUSIVE			0x10
>  #define PERF_PMU_CAP_ITRACE			0x20
>  #define PERF_PMU_CAP_HETEROGENEOUS_CPUS		0x40
> +#define PERF_PMU_CAP_EXCLUDE			0x80
>  
>  /**
>   * struct pmu - generic performance monitoring unit
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 84530ab358c3..d76b724177b9 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -9772,6 +9772,14 @@ static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
>  	if (ctx)
>  		perf_event_ctx_unlock(event->group_leader, ctx);
>  
> +	if (!ret) {
> +		if ((pmu->capabilities & PERF_PMU_CAP_EXCLUDE) ||
> +		    event_has_exclude_flags(event)) {
> +			event->destroy(event);
> +			ret = -EINVAL;
> +		}
> +	}
> +

I don't quite follow this logic. Should that not have been:

if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUDE) &&
     event_has_exclude_flags(event)) {

Meaning that if an event has any exclude flags but the pmu doesn't
have the capability to handle them then error.

If you're happy with my proposed logic, then would it also make
sense to move this before the call to the pmu->event_init ?

Thanks,

Andrew Murray

>  	if (ret)
>  		module_put(pmu->module);
>  
>
Peter Zijlstra Nov. 22, 2018, 12:26 p.m. UTC | #3
On Thu, Nov 22, 2018 at 12:21:43PM +0000, Andrew Murray wrote:
> On Mon, Nov 19, 2018 at 02:08:00PM +0100, Peter Zijlstra wrote:

> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 84530ab358c3..d76b724177b9 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -9772,6 +9772,14 @@ static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
> >  	if (ctx)
> >  		perf_event_ctx_unlock(event->group_leader, ctx);
> >  
> > +	if (!ret) {
> > +		if ((pmu->capabilities & PERF_PMU_CAP_EXCLUDE) ||
> > +		    event_has_exclude_flags(event)) {
> > +			event->destroy(event);
> > +			ret = -EINVAL;
> > +		}
> > +	}
> > +
> 
> I don't quite follow this logic. Should that not have been:
> 
> if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUDE) &&
>      event_has_exclude_flags(event)) {
> 
> Meaning that if an event has any exclude flags but the pmu doesn't
> have the capability to handle them then error.

Uhm, yes. Brainfart on my side that.

> If you're happy with my proposed logic, then would it also make
> sense to move this before the call to the pmu->event_init ?

I'm not sure that can work; I think we need ->event_init() first such
that it can -ENOENT. Only after ->event_init() returns success can we be
certain of @pmu.
Andrew Murray Nov. 22, 2018, 12:59 p.m. UTC | #4
On Thu, Nov 22, 2018 at 01:26:37PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 22, 2018 at 12:21:43PM +0000, Andrew Murray wrote:
> > On Mon, Nov 19, 2018 at 02:08:00PM +0100, Peter Zijlstra wrote:
> 
> > > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > > index 84530ab358c3..d76b724177b9 100644
> > > --- a/kernel/events/core.c
> > > +++ b/kernel/events/core.c
> > > @@ -9772,6 +9772,14 @@ static int perf_try_init_event(struct pmu *pmu, struct perf_event *event)
> > >  	if (ctx)
> > >  		perf_event_ctx_unlock(event->group_leader, ctx);
> > >  
> > > +	if (!ret) {
> > > +		if ((pmu->capabilities & PERF_PMU_CAP_EXCLUDE) ||
> > > +		    event_has_exclude_flags(event)) {
> > > +			event->destroy(event);
> > > +			ret = -EINVAL;
> > > +		}
> > > +	}
> > > +
> > 
> > I don't quite follow this logic. Should that not have been:
> > 
> > if (!(pmu->capabilities & PERF_PMU_CAP_EXCLUDE) &&
> >      event_has_exclude_flags(event)) {
> > 
> > Meaning that if an event has any exclude flags but the pmu doesn't
> > have the capability to handle them then error.
> 
> Uhm, yes. Brainfart on my side that.
> 
> > If you're happy with my proposed logic, then would it also make
> > sense to move this before the call to the pmu->event_init ?
> 
> I'm not sure that can work; I think we need ->event_init() first such
> that it can -ENOENT. Only after ->event_init() returns success can we be
> certain of @pmu.

Ah yes I see now. Until event_init doesn't return -ENOENT we can't be sure
that this will be the PMU we use (as per the other calls to
perf_try_init_event in perf_init_event).

Thanks,

Andrew Murray