perf pmu interface -v2
Subsystems (9)
cover perf pmu interface -v2
These patches prepare the perf code for multiple pmus (no user interface yet, Lin Ming is working on that). These patches remove all weak functions and rework the struct pmu interface.
The patches are boot tested on x86_64 and compile tested on: powerpc (!fsl, what config is that?), sparc and arm (sorry no SH compiler)
On x86 perf stat and record with both software and hardware events still worked.
I changed all (hardware) pmu implementations so there's a fair chance I messed something up, please have a look at it.
If people agree with this, I'll continue with the per-pmu context stuff I talked about last time, which should get us the hardware write batching back.
PATCH 1/11 perf, x86: Fix Nehalem PMU quirk
The idea was to run all three counters, which means we need to program 7 into the enable mask, not 3 (which is two bits).
---
arch/x86/kernel/cpu/perf_event_intel.c +1 -1
@@ -504,7 +504,7 @@ static void intel_pmu_nhm_enable_all(intwrmsrl (MSR_ARCH_PERFMON_EVENTSEL0 +1 ,0x4300B1 );wrmsrl (MSR_ARCH_PERFMON_EVENTSEL0 +2 ,0x4300B5 ); -wrmsrl (MSR_CORE_PERF_GLOBAL_CTRL ,0x3 ); +wrmsrl (MSR_CORE_PERF_GLOBAL_CTRL ,0x7 );wrmsrl (MSR_CORE_PERF_GLOBAL_CTRL ,0x0 );for (i =0 ; i <3 ; i++) {
PATCH 2/11 perf: Fix argument of perf_arch_fetch_caller_regs
In reply to Peter ZijlstraFrom: Nobuhiro Iwamatsu <[email protected]>
"struct regs" was set to argument of perf_arch_fetch_caller_regs. "struct pt_regs" is correct.
LKML-Reference: <[email protected]>
--- include/linux/perf_event.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/perf_event.h +1 -1
@@ -971,7 +971,7 @@ extern void __perf_sw_event(u32, u64, in#ifndef perf_arch_fetch_caller_regsstatic inline void -perf_arch_fetch_caller_regs (struct regs *regs,unsigned long ip) { } +perf_arch_fetch_caller_regs (struct pt_regs *regs,unsigned long ip) { }#endif /*
PATCH 3/11 perf, sparc64: Fix maybe_change_configuration() PCR setting.
In reply to Peter ZijlstraFrom: David S. Miller <[email protected]>
Need to mask out the existing event bits before OR'ing in the new ones.
--- arch/sparc/kernel/perf_event.c | 1 + 1 file changed, 1 insertion(+)
arch/sparc/kernel/perf_event.c +1 -0
@@ -657,6 +657,7 @@ static u64 maybe_change_configuration(st cpuc->current_idx[i] = idx; enc =perf_event_get_enc (cpuc->events[i]); + pcr &= ~mask_for_index (idx); pcr |=event_encoding (enc, idx); } out:
RFC PATCH 4/11 perf: deconstify struct pmu
In reply to Peter Zijlstrased -ie 's/const struct pmu\>/struct pmu/g' git grep -l "const struct pmu\>"
--- arch/arm/kernel/perf_event.c | 2 +- arch/powerpc/kernel/perf_event.c | 8 ++++---- arch/powerpc/kernel/perf_event_fsl_emb.c | 2 +- arch/sh/kernel/perf_event.c | 4 ++-- arch/sparc/kernel/perf_event.c | 10 +++++----- arch/x86/kernel/cpu/perf_event.c | 14 +++++++------- include/linux/perf_event.h | 10 +++++----- kernel/perf_event.c | 26 +++++++++++++------------- 8 files changed, 38 insertions(+), 38 deletions(-)
arch/arm/kernel/perf_event.c +1 -1
@@ -491,7 +491,7 @@ __hw_perf_event_init(struct perf_event *return err; } -const struct pmu * +struct pmu *hw_perf_event_init (struct perf_event *event) {int err =0 ;
arch/powerpc/kernel/perf_event.c +4 -4
@@ -854,7 +854,7 @@ static void power_pmu_unthrottle(struct* Set the flag to make pmu::enable() not perform the * schedulability test, it will be performed at commit time */ -void power_pmu_start_txn (const struct pmu *pmu) +void power_pmu_start_txn (struct pmu *pmu) {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events);
@@ -867,7 +867,7 @@ void power_pmu_start_txn(const struct pm* Clear the flag and pmu::enable() will perform the * schedulability test. */ -void power_pmu_cancel_txn (const struct pmu *pmu) +void power_pmu_cancel_txn (struct pmu *pmu) {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events);
@@ -879,7 +879,7 @@ void power_pmu_cancel_txn(const struct p* Perform the group schedulability test as a whole * Return 0 if success */ -int power_pmu_commit_txn (const struct pmu *pmu) +int power_pmu_commit_txn (struct pmu *pmu) {struct cpu_hw_events *cpuhw;long i, n;
@@ -1011,7 +1011,7 @@ static int hw_perf_cache_event(u64 confireturn 0 ; } -const struct pmu *hw_perf_event_init (struct perf_event *event) +struct pmu *hw_perf_event_init (struct perf_event *event) {u64 ev;unsigned long flags;
arch/powerpc/kernel/perf_event_fsl_emb.c +1 -1
@@ -428,7 +428,7 @@ static int hw_perf_cache_event(u64 confireturn 0 ; } -const struct pmu *hw_perf_event_init (struct perf_event *event) +struct pmu *hw_perf_event_init (struct perf_event *event) {u64 ev;struct perf_event *events[MAX_HWEVENTS ];
arch/sh/kernel/perf_event.c +2 -2
@@ -257,13 +257,13 @@ static void sh_pmu_read(struct perf_evensh_perf_event_update (event, &event->hw, event->hw.idx); } -static const struct pmu pmu = { +static struct pmu pmu = { .enable = sh_pmu_enable, .disable = sh_pmu_disable, .read = sh_pmu_read, }; -const struct pmu *hw_perf_event_init (struct perf_event *event) +struct pmu *hw_perf_event_init (struct perf_event *event) {int err =__hw_perf_event_init (event);if (unlikely (err)) {
arch/sparc/kernel/perf_event.c +5 -5
@@ -1098,7 +1098,7 @@ static int __hw_perf_event_init(struct p* Set the flag to make pmu::enable() not perform the * schedulability test, it will be performed at commit time */ -static void sparc_pmu_start_txn (const struct pmu *pmu) +static void sparc_pmu_start_txn (struct pmu *pmu) {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events);
@@ -1110,7 +1110,7 @@ static void sparc_pmu_start_txn(const st* Clear the flag and pmu::enable() will perform the * schedulability test. */ -static void sparc_pmu_cancel_txn (const struct pmu *pmu) +static void sparc_pmu_cancel_txn (struct pmu *pmu) {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events);
@@ -1122,7 +1122,7 @@ static void sparc_pmu_cancel_txn(const s* Perform the group schedulability test as a whole * Return 0 if success */ -static int sparc_pmu_commit_txn (const struct pmu *pmu) +static int sparc_pmu_commit_txn (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);int n;
@@ -1141,7 +1141,7 @@ static int sparc_pmu_commit_txn(const streturn 0 ; } -static const struct pmu pmu = { +static struct pmu pmu = { .enable = sparc_pmu_enable, .disable = sparc_pmu_disable, .read = sparc_pmu_read,
@@ -1151,7 +1151,7 @@ static const struct pmu pmu = { .commit_txn = sparc_pmu_commit_txn, }; -const struct pmu *hw_perf_event_init (struct perf_event *event) +struct pmu *hw_perf_event_init (struct perf_event *event) {int err =__hw_perf_event_init (event);
arch/x86/kernel/cpu/perf_event.c +7 -7
@@ -618,7 +618,7 @@ static void x86_pmu_enable_all(int added } } -static const struct pmu pmu; +static struct pmu pmu;static inline int is_x86_event (struct perf_event *event) {
@@ -1394,7 +1394,7 @@ static inline void x86_pmu_read(struct p* Set the flag to make pmu::enable() not perform the * schedulability test, it will be performed at commit time */ -static void x86_pmu_start_txn (const struct pmu *pmu) +static void x86_pmu_start_txn (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);
@@ -1407,7 +1407,7 @@ static void x86_pmu_start_txn(const stru* Clear the flag and pmu::enable() will perform the * schedulability test. */ -static void x86_pmu_cancel_txn (const struct pmu *pmu) +static void x86_pmu_cancel_txn (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);
@@ -1424,7 +1424,7 @@ static void x86_pmu_cancel_txn(const str* Perform the group schedulability test as a whole * Return 0 if success */ -static int x86_pmu_commit_txn (const struct pmu *pmu) +static int x86_pmu_commit_txn (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);int assign[X86_PMC_IDX_MAX ];
@@ -1450,7 +1450,7 @@ static int x86_pmu_commit_txn(const strureturn 0 ; } -static const struct pmu pmu = { +static struct pmu pmu = { .enable = x86_pmu_enable, .disable = x86_pmu_disable, .start = x86_pmu_start,
@@ -1536,9 +1536,9 @@ out:return ret; } -const struct pmu *hw_perf_event_init (struct perf_event *event) +struct pmu *hw_perf_event_init (struct perf_event *event) { -const struct pmu *tmp; +struct pmu *tmp;int err; err =__hw_perf_event_init (event);
include/linux/perf_event.h +5 -5
@@ -576,19 +576,19 @@ struct pmu {* Start the transaction, after this ->enable() doesn't need * to do schedulability tests. */ -void (*start_txn) (const struct pmu *pmu); +void (*start_txn) (struct pmu *pmu);/* * If ->start_txn() disabled the ->enable() schedulability test * then ->commit_txn() is required to perform one. On success * the transaction is closed. On error the transaction is kept * open until ->cancel_txn() is called. */ -int (*commit_txn) (const struct pmu *pmu); +int (*commit_txn) (struct pmu *pmu);/* * Will cancel the transaction, assumes ->disable() is called for * each successfull ->enable() during the transaction. */ -void (*cancel_txn) (const struct pmu *pmu); +void (*cancel_txn) (struct pmu *pmu); };/**
@@ -667,7 +667,7 @@ struct perf_event {int nr_siblings;int group_flags;struct perf_event *group_leader; -const struct pmu *pmu; +struct pmu *pmu;enum perf_event_active_state state;unsigned int attach_state;
@@ -845,7 +845,7 @@ struct perf_output_handle {*/ extern int perf_max_events; -extern const struct pmu *hw_perf_event_init (struct perf_event *event); +extern struct pmu *hw_perf_event_init (struct perf_event *event);extern void perf_event_task_sched_in (struct task_struct *task);extern void perf_event_task_sched_out (struct task_struct *task,struct task_struct *next);
kernel/perf_event.c +13 -13
@@ -75,7 +75,7 @@ static DEFINE_SPINLOCK(perf_resource_loc/* * Architecture provided APIs - weak aliases: */ -extern __weak const struct pmu *hw_perf_event_init (struct perf_event *event) +extern __weak struct pmu *hw_perf_event_init (struct perf_event *event) {return NULL ; }
@@ -673,7 +673,7 @@ group_sched_in(struct perf_event *group_ struct perf_event_context *ctx) {struct perf_event *event, *partial_group =NULL ; -const struct pmu *pmu = group_event->pmu; +struct pmu *pmu = group_event->pmu;bool txn = false;if (group_event->state ==PERF_EVENT_STATE_OFF )
@@ -4291,7 +4291,7 @@ static int perf_swevent_int(struct perf_return 0 ; } -static const struct pmu perf_ops_generic = { +static struct pmu perf_ops_generic = { .enable = perf_swevent_enable, .disable = perf_swevent_disable, .start = perf_swevent_int,
@@ -4404,7 +4404,7 @@ static void cpu_clock_perf_event_read(stcpu_clock_perf_event_update (event); } -static const struct pmu perf_ops_cpu_clock = { +static struct pmu perf_ops_cpu_clock = { .enable = cpu_clock_perf_event_enable, .disable = cpu_clock_perf_event_disable, .read = cpu_clock_perf_event_read,
@@ -4461,7 +4461,7 @@ static void task_clock_perf_event_read(stask_clock_perf_event_update (event, time); } -static const struct pmu perf_ops_task_clock = { +static struct pmu perf_ops_task_clock = { .enable = task_clock_perf_event_enable, .disable = task_clock_perf_event_disable, .read = task_clock_perf_event_read,
@@ -4575,7 +4575,7 @@ static int swevent_hlist_get(struct perf#ifdef CONFIG_EVENT_TRACING -static const struct pmu perf_ops_tracepoint = { +static struct pmu perf_ops_tracepoint = { .enable = perf_trace_enable, .disable = perf_trace_disable, .start = perf_swevent_int,
@@ -4639,7 +4639,7 @@ static void tp_perf_event_destroy(structperf_trace_destroy (event); } -static const struct pmu *tp_perf_event_init (struct perf_event *event) +static struct pmu *tp_perf_event_init (struct perf_event *event) {int err;
@@ -4686,7 +4686,7 @@ static void perf_event_free_filter(struc#else -static const struct pmu *tp_perf_event_init (struct perf_event *event) +static struct pmu *tp_perf_event_init (struct perf_event *event) {return NULL ; }
@@ -4708,7 +4708,7 @@ static void bp_perf_event_destroy(structrelease_bp_slot (event); } -static const struct pmu *bp_perf_event_init (struct perf_event *bp) +static struct pmu *bp_perf_event_init (struct perf_event *bp) {int err;
@@ -4732,7 +4732,7 @@ void perf_bp_event(struct perf_event *bp perf_swevent_add(bp, 1, 1, &sample, regs); }#else -static const struct pmu *bp_perf_event_init (struct perf_event *bp) +static struct pmu *bp_perf_event_init (struct perf_event *bp) {return NULL ; }
@@ -4754,9 +4754,9 @@ static void sw_perf_event_destroy(structswevent_hlist_put (event); } -static const struct pmu *sw_perf_event_init (struct perf_event *event) +static struct pmu *sw_perf_event_init (struct perf_event *event) { -const struct pmu *pmu =NULL ; +struct pmu *pmu =NULL ;u64 event_id = event->attr.config;/*
@@ -4818,7 +4818,7 @@ perf_event_alloc(struct perf_event_attr perf_overflow_handler_t overflow_handler, gfp_t gfpflags) { -const struct pmu *pmu; +struct pmu *pmu;struct perf_event *event;struct hw_perf_event *hwc;long err;
RFC PATCH 5/11 perf: register pmu implementations
In reply to Peter ZijlstraSimple registration interface for struct pmu, this provides the infrastructure for removing all the weak functions.
--- arch/arm/kernel/perf_event.c | 36 + arch/powerpc/kernel/perf_event.c | 46 +- arch/powerpc/kernel/perf_event_fsl_emb.c | 31 - arch/sh/kernel/perf_event.c | 19 arch/sparc/kernel/perf_event.c | 29 - arch/x86/kernel/cpu/perf_event.c | 45 +- include/linux/perf_event.h | 10 kernel/hw_breakpoint.c | 35 + kernel/perf_event.c | 594 +++++++++++++++---------------- 9 files changed, 450 insertions(+), 395 deletions(-)
arch/arm/kernel/perf_event.c +24 -12
@@ -306,13 +306,6 @@ out:return err; } -static struct pmu pmu = { - .enable = armpmu_enable, - .disable = armpmu_disable, - .unthrottle = armpmu_unthrottle, - .read = armpmu_read, -}; -static int validate_event (struct cpu_hw_events *cpuc,struct perf_event *event)
@@ -491,13 +484,22 @@ __hw_perf_event_init(struct perf_event *return err; } -struct pmu * -hw_perf_event_init (struct perf_event *event) +static int armpmu_event_init (struct perf_event *event) {int err =0 ; +switch (event->attr.type) { +case PERF_TYPE_RAW : +case PERF_TYPE_HARDWARE : +case PERF_TYPE_HW_CACHE : +break ; + +default : +return -ENOENT ; + } +if (!armpmu) -return ERR_PTR (-ENODEV ); +return -ENODEV ; event->destroy = hw_perf_event_destroy;
@@ -518,15 +520,23 @@ hw_perf_event_init(struct perf_event *ev }if (err) -return ERR_PTR (err); +return err; err =__hw_perf_event_init (event);if (err)hw_perf_event_destroy (event); -return err ?ERR_PTR (err) : &pmu; +return err; } +static struct pmu pmu = { + .event_init = armpmu_event_init, + .enable = armpmu_enable, + .disable = armpmu_disable, + .unthrottle = armpmu_unthrottle, + .read = armpmu_read, +}; +void hw_perf_enable (void ) {
@@ -2994,6 +3004,8 @@ init_hw_perf_events(void) perf_max_events =-1 ; } + perf_pmu_register(&pmu) +return 0 ; }arch_initcall (init_hw_perf_events);
arch/powerpc/kernel/perf_event.c +24 -22
115 lines not on this page · raw message
arch/powerpc/kernel/perf_event_fsl_emb.c +16 -15
@@ -378,13 +378,6 @@ static void fsl_emb_pmu_unthrottle(struclocal_irq_restore (flags); } -static struct pmu fsl_emb_pmu = { - .enable = fsl_emb_pmu_enable, - .disable = fsl_emb_pmu_disable, - .read = fsl_emb_pmu_read, - .unthrottle = fsl_emb_pmu_unthrottle, -}; -/* * Release the PMU if this is the last perf_event. */
@@ -428,7 +421,7 @@ static int hw_perf_cache_event(u64 confireturn 0 ; } -struct pmu *hw_perf_event_init (struct perf_event *event) +static int fsl_emb_pmu_event_init (struct perf_event *event) {u64 ev;struct perf_event *events[MAX_HWEVENTS ];
@@ -456,12 +449,12 @@ struct pmu *hw_perf_event_init(struct pebreak ;default : -return ERR_PTR (-EINVAL ); +return -ENOENT ; } event->hw.config = ppmu->xlate_event (ev);if (!(event->hw.config &FSL_EMB_EVENT_VALID )) -return ERR_PTR (-EINVAL ); +return -EINVAL ;/* * If this is in a group, check if it can go on with all the
@@ -473,7 +466,7 @@ struct pmu *hw_perf_event_init(struct pe n =collect_events (event->group_leader, ppmu->n_counter -1 , events);if (n <0 ) -return ERR_PTR (-EINVAL ); +return -EINVAL ; }if (event->hw.config &FSL_EMB_EVENT_RESTRICTED ) {
@@ -484,7 +477,7 @@ struct pmu *hw_perf_event_init(struct pe }if (num_restricted >= ppmu->n_restricted) -return ERR_PTR (-EINVAL ); +return -EINVAL ; } event->hw.idx =-1 ;
@@ -523,11 +516,17 @@ struct pmu *hw_perf_event_init(struct pe } event->destroy = hw_perf_event_destroy; -if (err) -return ERR_PTR (err); -return &fsl_emb_pmu; +return err; } +static struct pmu fsl_emb_pmu = { + .event_init = fsl_emb_pmu_event_init, + .enable = fsl_emb_pmu_enable, + .disable = fsl_emb_pmu_disable, + .read = fsl_emb_pmu_read, + .unthrottle = fsl_emb_pmu_unthrottle, +}; +/* * A counter has overflowed; update its count and record * things if requested. Note that interrupts are hard-disabled
@@ -650,5 +649,7 @@ int register_fsl_emb_pmu(struct fsl_emb_pr_info ("%s performance monitor hardware support registered\n" , pmu->name); +perf_pmu_register (&fsl_emb_pmu); +return 0 ; }
arch/sh/kernel/perf_event.c +10 -9
@@ -257,24 +257,24 @@ static void sh_pmu_read(struct perf_evensh_perf_event_update (event, &event->hw, event->hw.idx); } -static struct pmu pmu = { - .enable = sh_pmu_enable, - .disable = sh_pmu_disable, - .read = sh_pmu_read, -}; - -struct pmu *hw_perf_event_init (struct perf_event *event) +static in sh_pmu_event_init (struct perf_event *event) {int err =__hw_perf_event_init (event);if (unlikely (err)) {if (event->destroy) event->destroy (event); -return ERR_PTR (err); } -return &pmu; +return err; } +static struct pmu pmu = { + .event_init = sh_pmu_event_init, + .enable = sh_pmu_enable, + .disable = sh_pmu_disable, + .read = sh_pmu_read, +}; +static void sh_pmu_setup (int cpu) {struct cpu_hw_events *cpuhw = &per_cpu (cpu_hw_events, cpu);
@@ -325,6 +325,7 @@ int __cpuinit register_sh_pmu(struct sh_WARN_ON (pmu->num_events >MAX_HWEVENTS ); +perf_pmu_register (&pmu);perf_cpu_notifier (sh_pmu_notifier);return 0 ; }
arch/sparc/kernel/perf_event.c +16 -13
@@ -1024,7 +1024,7 @@ out:return ret; } -static int __hw_perf_event_init (struct perf_event *event) +static int sparc_pmu_event_init (struct perf_event *event) {struct perf_event_attr *attr = &event->attr;struct perf_event *evts[MAX_HWEVENTS ];
@@ -1037,17 +1037,27 @@ static int __hw_perf_event_init(struct pif (atomic_read (&nmi_active) <0 )return -ENODEV ; -if (attr->type ==PERF_TYPE_HARDWARE ) { +switch (attr->type) { +case PERF_TYPE_HARDWARE :if (attr->config >= sparc_pmu->max_events)return -EINVAL ; pmap = sparc_pmu->event_map (attr->config); - }else if (attr->type ==PERF_TYPE_HW_CACHE ) { +break ; + +case PERF_TYPE_HW_CACHE : pmap =sparc_map_cache_event (attr->config);if (IS_ERR (pmap))return PTR_ERR (pmap); - }else +break ; + +case PERF_TYPE_RAW :return -EOPNOTSUPP ; +default : +return -ENOENT ; + + } +/* We save the enable bits in the config_base. */ hwc->config_base = sparc_pmu->irq_bit;if (!attr->exclude_user)
@@ -1142,6 +1152,7 @@ static int sparc_pmu_commit_txn(struct p }static struct pmu pmu = { + .event_init = sparc_pmu_event_init, .enable = sparc_pmu_enable, .disable = sparc_pmu_disable, .read = sparc_pmu_read,
@@ -1151,15 +1162,6 @@ static struct pmu pmu = { .commit_txn = sparc_pmu_commit_txn, }; -struct pmu *hw_perf_event_init (struct perf_event *event) -{ -int err =__hw_perf_event_init (event); - -if (err) -return ERR_PTR (err); -return &pmu; -} -void perf_event_print_debug (void ) {unsigned long flags;
@@ -1279,6 +1281,7 @@ void __init init_hw_perf_events(void)/* All sparc64 PMUs currently have 2 events. */ perf_max_events =2 ; +perf_pmu_register (&pmu);register_die_notifier (&perf_event_nmi_notifier); }
arch/x86/kernel/cpu/perf_event.c +28 -17
83 lines not on this page · raw message
include/linux/perf_event.h +9 -1
@@ -559,6 +559,13 @@ struct perf_event;* struct pmu - generic performance monitoring unit */ struct pmu { +struct list_head entry; + +/* +* Should return -ENOENT when the @event doesn't match this pmu +*/ +int (*event_init) (struct perf_event *event); +int (*enable) (struct perf_event *event);void (*disable) (struct perf_event *event);int (*start) (struct perf_event *event);
@@ -845,7 +852,8 @@ struct perf_output_handle {*/ extern int perf_max_events; -extern struct pmu *hw_perf_event_init (struct perf_event *event); +extern int perf_pmu_register (struct pmu *pmu); +extern void perf_pmu_unregister (struct pmu *pmu);extern void perf_event_task_sched_in (struct task_struct *task);extern void perf_event_task_sched_out (struct task_struct *task,struct task_struct *next);
kernel/hw_breakpoint.c +30 -5
@@ -549,6 +549,34 @@ static struct notifier_block hw_breakpoi .priority = 0x7fffffff }; +static void bp_perf_event_destroy (struct perf_event *event) +{ +release_bp_slot (event); +} + +static int hw_breakpoint_event_init (struct perf_event *bp) +{ +int err; + +if (bp->attr.type !=PERF_TYPE_BREAKPOINT ) +return -ENOENT ; + + err =register_perf_hw_breakpoint (bp); +if (err) +return err; + + bp->destroy = bp_perf_event_destroy; + +return 0 ; +} + +static struct pmu perf_breakpoint = { + .event_init = hw_breakpoint_event_init, + .enable = arch_install_hw_breakpoint, + .disable = arch_uninstall_hw_breakpoint, + .read = hw_breakpoint_pmu_read, +}; +static int __init init_hw_breakpoint (void ) {unsigned int **task_bp_pinned;
@@ -570,6 +598,8 @@ static int __init init_hw_breakpoint(voi constraints_initialized =1 ; +perf_pmu_register (&perf_breakpoint); +return register_die_notifier (&hw_breakpoint_exceptions_nb); err_alloc:
@@ -585,8 +615,3 @@ static int __init init_hw_breakpoint(voicore_initcall (init_hw_breakpoint); -struct pmu perf_ops_bp = { - .enable = arch_install_hw_breakpoint, - .disable = arch_uninstall_hw_breakpoint, - .read = hw_breakpoint_pmu_read, -};
kernel/perf_event.c +293 -301
718 lines not on this page · raw message
Re: [RFC][PATCH 05/11] perf: register pmu implementations
kernel/hw_breakpoint.c static struct notifier_block hw_breakpoi · line 568
Quoted 8 lines · Peter Zijlstra
kernel/hw_breakpoint.c +8
-0+if (bp->attr.type !=PERF_TYPE_BREAKPOINT ) +return -ENOENT ; + + err =register_perf_hw_breakpoint (bp); +if (err) +return err; + + bp->destroy = bp_perf_event_destroy;
Seems it would make sense to also have destroy in the pmu, it's the same along every events in the same class right?
But this can be for later.
Quoted 35 lines
kernel/perf_event.c +32
-2+static LIST_HEAD (pmus); +static DEFINE_MUTEX (pmus_lock); +static struct srcu_struct pmus_srcu; + +int perf_pmu_register (struct pmu *pmu) +{ +mutex_lock (&pmus_lock); +list_add_rcu (&pmu->entry, &pmus); +mutex_unlock (&pmus_lock); + +return 0 ; +} + +void perf_pmu_unregister (struct pmu *pmu) +{ +mutex_lock (&pmus_lock); +list_del_rcu (&pmu->entry); +mutex_unlock (&pmus_lock); -atomic_inc (&perf_swevent_enabled[event_id]); - event->destroy = sw_perf_event_destroy; +synchronize_srcu (&pmus_srcu); +} + +struct pmu *perf_init_event (struct perf_event *event) +{ +struct pmu *pmu =NULL ; +int idx; + + idx =srcu_read_lock (&pmus_srcu); +list_for_each_entry_rcu (pmu, &pmus, entry) { +int ret = pmu->event_init (event); +if (!ret) +break ; +if (ret != -ENOENT ) {
kernel/perf_event.c static void perf_event_free_filter(struc · line 4827
Quoted 10 lines
kernel/perf_event.c +3
-2+ pmu =ERR_PTR (ret); +break ; } - pmu = &perf_ops_generic; -break ; } +srcu_read_unlock (&pmus_srcu, idx);return pmu; }
I'm still not sure why all this locking is needed. We don't even support pmus in modules.
Is there something coming soon that will use this? I remember something about KVM.
And who will have to use srcu? It seems the event fastpath would be concerned, right? Will that have an impact on the performances?
Quoted 8 lines
kernel/perf_event.c +1
-1@@ -5743,15 +5742,15 @@ perf_cpu_notify(struct notifier_block *s {unsigned int cpu = (long )hcpu; -switch (action) { +switch (action & ~CPU_TASKS_FROZEN ) {case CPU_UP_PREPARE :
kernel/perf_event.c perf_cpu_notify(struct notifier_block *s · line 5755
Quoted 10 lines
kernel/perf_event.c +2
-2-case CPU_UP_PREPARE_FROZEN : +case CPU_DOWN_FAILED :perf_event_init_cpu (cpu);break ; +case CPU_UP_CANCELED :case CPU_DOWN_PREPARE : -case CPU_DOWN_PREPARE_FROZEN :perf_event_exit_cpu (cpu);break ;
That doesn't seem to be related to this patch initial topic.
Peter Zijlstra
maintainerRe: [RFC][PATCH 05/11] perf: register pmu implementations
Quoted 13 lines · Frederic Weisbecker
kernel/hw_breakpoint.c static struct notifier_block hw_breakpoi · line 568
Quoted 8 lines · Peter Zijlstra
kernel/hw_breakpoint.c +8
-0+if (bp->attr.type !=PERF_TYPE_BREAKPOINT ) +return -ENOENT ; + + err =register_perf_hw_breakpoint (bp); +if (err) +return err; + + bp->destroy = bp_perf_event_destroy;Seems it would make sense to also have destroy in the pmu, it's the same along every events in the same class right?
Quoted 1 line
But this can be for later.
Ah, indeed.
Quoted 51 lines
Quoted 35 lines
kernel/perf_event.c +32
-2+static LIST_HEAD (pmus); +static DEFINE_MUTEX (pmus_lock); +static struct srcu_struct pmus_srcu; + +int perf_pmu_register (struct pmu *pmu) +{ +mutex_lock (&pmus_lock); +list_add_rcu (&pmu->entry, &pmus); +mutex_unlock (&pmus_lock); + +return 0 ; +} + +void perf_pmu_unregister (struct pmu *pmu) +{ +mutex_lock (&pmus_lock); +list_del_rcu (&pmu->entry); +mutex_unlock (&pmus_lock); -atomic_inc (&perf_swevent_enabled[event_id]); - event->destroy = sw_perf_event_destroy; +synchronize_srcu (&pmus_srcu); +} + +struct pmu *perf_init_event (struct perf_event *event) +{ +struct pmu *pmu =NULL ; +int idx; + + idx =srcu_read_lock (&pmus_srcu); +list_for_each_entry_rcu (pmu, &pmus, entry) { +int ret = pmu->event_init (event); +if (!ret) +break ; +if (ret != -ENOENT ) {kernel/perf_event.c static void perf_event_free_filter(struc · line 4827
Quoted 10 lines
kernel/perf_event.c +3
-2+ pmu =ERR_PTR (ret); +break ; } - pmu = &perf_ops_generic; -break ; } +srcu_read_unlock (&pmus_srcu, idx);return pmu; }I'm still not sure why all this locking is needed. We don't even support pmus in modules.
Quoted 2 lines
Is there something coming soon that will use this? I remember something about KVM.
Possibly, not sure. We could put the unregister thing in a later patch, but I wanted to make sure it was sanely possibly and its only a few lines of code.
Quoted 2 lines
And who will have to use srcu? It seems the event fastpath would be concerned, right? Will that have an impact on the performances?
Only event creation like above (perf_init_event) will have to use SRCU, so not really a hot path.
Quoted 13 lines
Quoted 13 lines
kernel/perf_event.c +2
-2@@ -5743,15 +5742,15 @@ perf_cpu_notify(struct notifier_block *s {unsigned int cpu = (long )hcpu; -switch (action) { +switch (action & ~CPU_TASKS_FROZEN ) {case CPU_UP_PREPARE : -case CPU_UP_PREPARE_FROZEN : +case CPU_DOWN_FAILED :perf_event_init_cpu (cpu);break ;
Quoted 9 lines
kernel/perf_event.c perf_cpu_notify(struct notifier_block *s · line 5755
Quoted 5 lines
kernel/perf_event.c +1
-1+case CPU_UP_CANCELED :case CPU_DOWN_PREPARE : -case CPU_DOWN_PREPARE_FROZEN :perf_event_exit_cpu (cpu);break ;That doesn't seem to be related to this patch initial topic.
Ah indeed, that needs to go live in its own patch.
Re: [RFC][PATCH 05/11] perf: register pmu implementations
Quoted 11 lines · Peter Zijlstra
Quoted 11 lines
kernel/perf_event.c static void perf_event_free_filter(struc · line 4827
Quoted 5 lines
kernel/perf_event.c +1
-0} +srcu_read_unlock (&pmus_srcu, idx);return pmu; }I'm still not sure why all this locking is needed. We don't even support pmus in modules.
Quoted 6 lines
Quoted 2 lines
Is there something coming soon that will use this? I remember something about KVM.
Possibly, not sure. We could put the unregister thing in a later patch, but I wanted to make sure it was sanely possibly and its only a few lines of code.
Ok.
Quoted 5 lines
Quoted 2 lines
And who will have to use srcu? It seems the event fastpath would be concerned, right? Will that have an impact on the performances?
Only event creation like above (
perf_init_event) will have to use SRCU, so not really a hot path.
Ah I see. The event itself is synchronized against the fast-path using rcu. And then pmus themselves would be synchronized against events. Right that makes sense.
But then why RCU (or SRCU, whatever)? I mean parent event creation is quite rare. And child events won't need to be synchronized as far as the parent keeps a reference to the pmu.
Re: [RFC][PATCH 05/11] perf: register pmu implementations
In reply to Peter ZijlstraQuoted 2 lines · Peter Zijlstra
Simple registration interface for struct pmu, this provides the infrastructure for removing all the weak functions.
Seems to work on powerpc, but the sh bits don't seem quite right:
Quoted 6 lines
Index:
linux-2.6/arch/sh/kernel/perf_event.c
===================================================================arch/sh/kernel/perf_event.c +0
-0@@ -257,24 +257,24 @@ static void sh_pmu_read(struct perf_evensh_perf_event_update (event, &event->hw, event->hw.idx);
arch/sh/kernel/perf_event.c static void sh_pmu_read(struct perf_even · line 260
Quoted 10 lines
arch/sh/kernel/perf_event.c +1
-7} -static struct pmu pmu = { - .enable = sh_pmu_enable, - .disable = sh_pmu_disable, - .read = sh_pmu_read, -}; - -struct pmu *hw_perf_event_init (struct perf_event *event) +static in sh_pmu_event_init (struct perf_event *event)
int?
arch/sh/kernel/perf_event.c static void sh_pmu_read(struct perf_even · line 262
Quoted 2 lines
arch/sh/kernel/perf_event.c +0
-0{int err =__hw_perf_event_init (event);
We need a switch on event->attr.type so we return -ENOENT if it's not PERF_TYPE_{HARDWARE,HW_CACHE,RAW}. As it is we don't ever return -ENOENT, which might stop software and tracepoint events from working.
Paul.
Peter Zijlstra
maintainerRe: [RFC][PATCH 05/11] perf: register pmu implementations
Quoted 4 lines · Paul Mackerras
arch/sh/kernel/perf_event.c static void sh_pmu_read(struct perf_even · line 260
Quoted 2 lines
arch/sh/kernel/perf_event.c +1
-1-struct pmu *hw_perf_event_init (struct perf_event *event) +static in sh_pmu_event_init (struct perf_event *event)int?
Argh, I fixed that a few times, but the hunk keeps slipping into different patches.. cured.
Quoted 6 lines
Quoted 2 lines
{
int err =__hw_perf_event_init(event);We need a switch on
event->attr.typeso we return-ENOENTif it's not PERF_TYPE_{HARDWARE,HW_CACHE,RAW}. As it is we don't ever return-ENOENT, which might stop software and tracepoint events from working.
Aaah, indeed! That is why Matt's perf record broke, perf record defaults to -e cycles which automagically falls back to a software timer, which then doesn't work.
RFC PATCH 6/11 perf: Unindent labels
In reply to Peter ZijlstraFixup random annoying style bits
--- kernel/perf_event.c | 43 ++++++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 19 deletions(-)
kernel/perf_event.c +24 -19
@@ -147,7 +147,7 @@ perf_lock_task_context(struct task_strucstruct perf_event_context *ctx;rcu_read_lock (); - retry: +retry: ctx =rcu_dereference (task->perf_event_ctxp);if (ctx) {/*
@@ -601,7 +601,7 @@ void perf_event_disable(struct perf_evenreturn ; } - retry: +retry:task_oncpu_function_call (task, __perf_event_disable, event);raw_spin_lock_irq (&ctx->lock);
@@ -831,7 +831,7 @@ static void __perf_install_in_context(voif (!err && !ctx->task && cpuctx->max_pertask) cpuctx->max_pertask--; - unlock: +unlock:perf_enable ();raw_spin_unlock (&ctx->lock);
@@ -904,10 +904,12 @@ static void __perf_event_mark_enabled(st event->state =PERF_EVENT_STATE_INACTIVE ; event->tstamp_enabled = ctx->time - event->total_time_enabled; -list_for_each_entry (sub, &event->sibling_list, group_entry) -if (sub->state >=PERF_EVENT_STATE_INACTIVE ) +list_for_each_entry (sub, &event->sibling_list, group_entry) { +if (sub->state >=PERF_EVENT_STATE_INACTIVE ) { sub->tstamp_enabled = ctx->time - sub->total_time_enabled; + } + } }/*
@@ -973,7 +975,7 @@ static void __perf_event_enable(void *in } } - unlock: +unlock:raw_spin_unlock (&ctx->lock); }
@@ -1014,7 +1016,7 @@ void perf_event_enable(struct perf_eventif (event->state ==PERF_EVENT_STATE_ERROR ) event->state =PERF_EVENT_STATE_OFF ; - retry: +retry:raw_spin_unlock_irq (&ctx->lock);task_oncpu_function_call (task, __perf_event_enable, event);
@@ -1034,7 +1036,7 @@ void perf_event_enable(struct perf_eventif (event->state ==PERF_EVENT_STATE_OFF )__perf_event_mark_enabled (event, ctx); - out: +out:raw_spin_unlock_irq (&ctx->lock); }
@@ -1074,17 +1076,19 @@ static void ctx_sched_out(struct perf_evif (!ctx->nr_active) goto out_enable; -if (event_type &EVENT_PINNED ) +if (event_type &EVENT_PINNED ) {list_for_each_entry (event, &ctx->pinned_groups, group_entry)group_sched_out (event, cpuctx, ctx); + } -if (event_type &EVENT_FLEXIBLE ) +if (event_type &EVENT_FLEXIBLE ) {list_for_each_entry (event, &ctx->flexible_groups, group_entry)group_sched_out (event, cpuctx, ctx); + } out_enable:perf_enable (); - out: +out:raw_spin_unlock (&ctx->lock); }
@@ -1323,9 +1327,10 @@ ctx_flexible_sched_in(struct perf_event_if (event->cpu !=-1 && event->cpu !=smp_processor_id ())continue ; -if (group_can_go_on (event, cpuctx, can_add_hw)) +if (group_can_go_on (event, cpuctx, can_add_hw)) {if (group_sched_in (event, cpuctx, ctx)) can_add_hw =0 ; + } } }
@@ -1355,7 +1360,7 @@ ctx_sched_in(struct perf_event_context *ctx_flexible_sched_in (ctx, cpuctx);perf_enable (); - out: +out:raw_spin_unlock (&ctx->lock); }
@@ -1696,7 +1701,7 @@ static void perf_event_enable_on_exec(straw_spin_unlock (&ctx->lock);perf_event_task_sched_in (task); - out: +out:local_irq_restore (flags); }
@@ -1825,7 +1830,7 @@ static struct perf_event_context *find_gif (!ptrace_may_access (task,PTRACE_MODE_READ )) goto errout; - retry: +retry: ctx =perf_lock_task_context (task, &flags);if (ctx) {unclone_ctx (ctx);
@@ -1853,7 +1858,7 @@ static struct perf_event_context *find_gput_task_struct (task);return ctx; - errout: +errout:put_task_struct (task);return ERR_PTR (err); }
@@ -3044,7 +3049,7 @@ again:if (handle->wakeup !=local_read (&buffer->wakeup))perf_output_wakeup (handle); - out: +out:preempt_enable (); }
@@ -4352,7 +4357,7 @@ static int swevent_hlist_get_cpu(structrcu_assign_pointer (cpuctx->swevent_hlist, hlist); } cpuctx->hlist_refcount++; - exit: +exit:mutex_unlock (&cpuctx->hlist_mutex);return err;
@@ -4377,7 +4382,7 @@ static int swevent_hlist_get(struct perfput_online_cpus ();return 0 ; - fail: +fail:for_each_possible_cpu (cpu) {if (cpu == failed_cpu)break ;
RFC PATCH 7/11 perf: Reduce perf_disable() usage
In reply to Peter ZijlstraSince the current perf_disable() usage is only an optimization, remove it for now. This eases the removal of the weak hw_perf_enable interface.
--- arch/powerpc/kernel/perf_event.c | 3 ++ arch/powerpc/kernel/perf_event_fsl_emb.c | 8 +++++- arch/sparc/kernel/perf_event.c | 3 ++ arch/x86/kernel/cpu/perf_event.c | 22 +++++++++++------- include/linux/perf_event.h | 20 ++++++++-------- kernel/perf_event.c | 37 ------------------------------- 6 files changed, 37 insertions(+), 56 deletions(-)
include/linux/perf_event.h +10 -10
@@ -562,26 +562,26 @@ struct pmu {struct list_head entry;/* -* Should return -ENOENT when the @event doesn't match this pmu +* Should return -ENOENT when the @event doesn't match this PMU. */ int (*event_init) (struct perf_event *event); -int (*enable) (struct perf_event *event); +int (*enable) (struct perf_event *event);void (*disable) (struct perf_event *event); -int (*start) (struct perf_event *event); +int (*start) (struct perf_event *event);void (*stop) (struct perf_event *event);void (*read) (struct perf_event *event);void (*unthrottle) (struct perf_event *event);/* -* Group events scheduling is treated as a transaction, add group -* events as a whole and perform one schedulability test. If the test -* fails, roll back the whole group +* Group events scheduling is treated as a transaction, add +* group events as a whole and perform one schedulability test. +* If the test fails, roll back the whole group */ /* -* Start the transaction, after this ->enable() doesn't need -* to do schedulability tests. +* Start the transaction, after this ->enable() doesn't need to +* do schedulability tests. */ void (*start_txn) (struct pmu *pmu);/*
@@ -592,8 +592,8 @@ struct pmu {*/ int (*commit_txn) (struct pmu *pmu);/* -* Will cancel the transaction, assumes ->disable() is called for -* each successfull ->enable() during the transaction. +* Will cancel the transaction, assumes ->disable() is called +* for each successfull ->enable() during the transaction. */ void (*cancel_txn) (struct pmu *pmu); };
kernel/perf_event.c +1 -36
@@ -460,11 +460,6 @@ static void __perf_event_remove_from_conreturn ;raw_spin_lock (&ctx->lock); -/* -* Protect the list operation against NMI by disabling the -* events on a global level. -*/ -perf_disable ();event_sched_out (event, cpuctx, ctx);
@@ -480,7 +475,6 @@ static void __perf_event_remove_from_con perf_max_events - perf_reserved_percpu); } -perf_enable ();raw_spin_unlock (&ctx->lock); }
@@ -785,12 +779,6 @@ static void __perf_install_in_context(vo ctx->is_active =1 ;update_context_time (ctx); -/* -* Protect the list operation against NMI by disabling the -* events on a global level. NOP for non NMI based events. -*/ -perf_disable (); -add_event_to_ctx (event, ctx);if (event->cpu !=-1 && event->cpu !=smp_processor_id ())
@@ -832,8 +820,6 @@ static void __perf_install_in_context(vo cpuctx->max_pertask--; unlock: -perf_enable (); -raw_spin_unlock (&ctx->lock); }
@@ -954,12 +940,10 @@ static void __perf_event_enable(void *inif (!group_can_go_on (event, cpuctx,1 )) { err = -EEXIST ; }else { -perf_disable ();if (event == leader) err =group_sched_in (event, cpuctx, ctx);else err =event_sched_in (event, cpuctx, ctx); -perf_enable (); }if (err) {
@@ -1072,9 +1056,8 @@ static void ctx_sched_out(struct perf_ev goto out;update_context_time (ctx); -perf_disable ();if (!ctx->nr_active) - goto out_enable; + goto out;if (event_type &EVENT_PINNED ) {list_for_each_entry (event, &ctx->pinned_groups, group_entry)
@@ -1085,9 +1068,6 @@ static void ctx_sched_out(struct perf_evlist_for_each_entry (event, &ctx->flexible_groups, group_entry)group_sched_out (event, cpuctx, ctx); } - - out_enable: -perf_enable (); out:raw_spin_unlock (&ctx->lock); }
@@ -1346,8 +1326,6 @@ ctx_sched_in(struct perf_event_context * ctx->timestamp =perf_clock (); -perf_disable (); -/* * First go through the list and put on any pinned groups * in order to give them the best chance of going on.
@@ -1359,7 +1337,6 @@ ctx_sched_in(struct perf_event_context *if (event_type &EVENT_FLEXIBLE )ctx_flexible_sched_in (ctx, cpuctx); -perf_enable (); out:raw_spin_unlock (&ctx->lock); }
@@ -1407,8 +1384,6 @@ void perf_event_task_sched_in(struct tasif (cpuctx->task_ctx == ctx)return ; -perf_disable (); -/* * We want to keep the following priority order: * cpu pinned (that don't need to move), task pinned,
@@ -1421,8 +1396,6 @@ void perf_event_task_sched_in(struct tasctx_sched_in (ctx, cpuctx,EVENT_FLEXIBLE ); cpuctx->task_ctx = ctx; - -perf_enable (); }#define MAX_INTERRUPTS (~0ULL)
@@ -1537,11 +1510,9 @@ static void perf_adjust_period(struct pe hwc->sample_period = sample_period;if (local64_read (&hwc->period_left) >8 *sample_period) { -perf_disable ();perf_event_stop (event);local64_set (&hwc->period_left,0 );perf_event_start (event); -perf_enable (); } }
@@ -1570,15 +1541,12 @@ static void perf_ctx_adjust_freq(struct*/ if (interrupts ==MAX_INTERRUPTS ) {perf_log_throttle (event,1 ); -perf_disable (); event->pmu->unthrottle (event); -perf_enable (); }if (!event->attr.freq || !event->attr.sample_freq)continue ; -perf_disable (); event->pmu->read (event); now =local64_read (&event->count); delta = now - hwc->freq_count_stamp;
@@ -1586,7 +1554,6 @@ static void perf_ctx_adjust_freq(structif (delta >0 )perf_adjust_period (event,TICK_NSEC , delta); -perf_enable (); }raw_spin_unlock (&ctx->lock); }
@@ -1629,7 +1596,6 @@ void perf_event_task_tick(struct task_stif (!rotate)return ; -perf_disable ();cpu_ctx_sched_out (cpuctx,EVENT_FLEXIBLE );if (ctx)task_ctx_sched_out (ctx,EVENT_FLEXIBLE );
@@ -1641,7 +1607,6 @@ void perf_event_task_tick(struct task_stcpu_ctx_sched_in (cpuctx,EVENT_FLEXIBLE );if (ctx)task_ctx_sched_in (curr,EVENT_FLEXIBLE ); -perf_enable (); } static int event_enable_on_exec(struct perf_event *event,
arch/powerpc/kernel/perf_event_fsl_emb.c +6 -2
@@ -262,7 +262,7 @@ static int collect_events(struct perf_evreturn n; } -/* perf must be disabled, context locked on entry */ +/* context locked on entry */ static int fsl_emb_pmu_enable (struct perf_event *event) {struct cpu_hw_events *cpuhw;
@@ -271,6 +271,7 @@ static int fsl_emb_pmu_enable(struct peru64 val;int i; +perf_disable (); cpuhw = &get_cpu_var (cpu_hw_events);if (event->hw.config &FSL_EMB_EVENT_RESTRICTED )
@@ -310,15 +311,17 @@ static int fsl_emb_pmu_enable(struct per ret =0 ; out:put_cpu_var (cpu_hw_events); +perf_enable ();return ret; } -/* perf must be disabled, context locked on entry */ +/* context locked on entry */ static void fsl_emb_pmu_disable (struct perf_event *event) {struct cpu_hw_events *cpuhw;int i = event->hw.idx; +perf_disable ();if (i <0 ) goto out;
@@ -346,6 +349,7 @@ static void fsl_emb_pmu_disable(struct p cpuhw->n_events--; out: +perf_enable ();put_cpu_var (cpu_hw_events); }
arch/x86/kernel/cpu/perf_event.c +14 -8
@@ -969,10 +969,11 @@ static int x86_pmu_enable(struct perf_ev hwc = &event->hw; +perf_disable (); n0 = cpuc->n_events; - n =collect_events (cpuc, event, false); -if (n <0 ) -return n; + ret = n =collect_events (cpuc, event, false); +if (ret <0 ) + goto out;/* * If group events scheduling transaction was started,
@@ -980,23 +981,26 @@ static int x86_pmu_enable(struct perf_ev* at commit time(->commit_txn) as a whole */ if (cpuc->group_flag &PERF_EVENT_TXN ) - goto out; + goto done_collect; ret = x86_pmu.schedule_events (cpuc, n, assign);if (ret) -return ret; + goto out;/* * copy new assignment, now we know it is possible * will be used by hw_perf_enable() */ memcpy (cpuc->assign, assign, n*sizeof (int )); -out: +done_collect: cpuc->n_events = n; cpuc->n_added += n - n0; cpuc->n_txn += n - n0; -return 0 ; + ret =0 ; +out: +perf_enable (); +return ret; }static int x86_pmu_start (struct perf_event *event)
@@ -1399,6 +1403,7 @@ static void x86_pmu_start_txn(struct pmu {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events); +perf_disable (); cpuc->group_flag |=PERF_EVENT_TXN ; cpuc->n_txn =0 ; }
@@ -1418,6 +1423,7 @@ static void x86_pmu_cancel_txn(struct pm*/ cpuc->n_added -= cpuc->n_txn; cpuc->n_events -= cpuc->n_txn; +perf_enable (); }/*
@@ -1447,7 +1453,7 @@ static int x86_pmu_commit_txn(struct pmumemcpy (cpuc->assign, assign, n*sizeof (int )); cpuc->group_flag &= ~PERF_EVENT_TXN ; - +perf_enable ();return 0 ; }
arch/powerpc/kernel/perf_event.c +3 -0
@@ -858,6 +858,7 @@ void power_pmu_start_txn(struct pmu *pmu {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); +perf_disable (); cpuhw->group_flag |=PERF_EVENT_TXN ; cpuhw->n_txn_start = cpuhw->n_events; }
@@ -872,6 +873,7 @@ void power_pmu_cancel_txn(struct pmu *pmstruct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); cpuhw->group_flag &= ~PERF_EVENT_TXN ; +perf_enable (); }/*
@@ -898,6 +900,7 @@ int power_pmu_commit_txn(struct pmu *pmu cpuhw->event[i]->hw.config = cpuhw->events[i]; cpuhw->group_flag &= ~PERF_EVENT_TXN ; +perf_enable ();return 0 ; }
arch/sparc/kernel/perf_event.c +3 -0
@@ -1112,6 +1112,7 @@ static void sparc_pmu_start_txn(struct p {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); +perf_disable (); cpuhw->group_flag |=PERF_EVENT_TXN ; }
@@ -1125,6 +1126,7 @@ static void sparc_pmu_cancel_txn(structstruct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); cpuhw->group_flag &= ~PERF_EVENT_TXN ; +perf_enable (); }/*
@@ -1148,6 +1150,7 @@ static int sparc_pmu_commit_txn(struct preturn -EAGAIN ; cpuc->group_flag &= ~PERF_EVENT_TXN ; +perf_enable ();return 0 ; }
RFC PATCH 8/11 perf: Per PMU disable
In reply to Peter ZijlstraChanges perf_disable() into perf_pmu_disable().
--- arch/arm/kernel/perf_event.c | 24 ++++++++++----------- arch/powerpc/kernel/perf_event.c | 26 ++++++++++++----------- arch/powerpc/kernel/perf_event_fsl_emb.c | 18 +++++++++------- arch/sh/kernel/perf_event.c | 34 ++++++++++++++++--------------- arch/sparc/kernel/perf_event.c | 20 ++++++++++-------- arch/x86/kernel/cpu/perf_event.c | 16 ++++++++------ include/linux/perf_event.h | 13 ++++++----- kernel/perf_event.c | 30 ++++++++++++++++----------- 8 files changed, 99 insertions(+), 82 deletions(-)
arch/arm/kernel/perf_event.c +12 -12
@@ -529,16 +529,7 @@ static int armpmu_event_init(struct perfreturn err; } -static struct pmu pmu = { - .event_init = armpmu_event_init, - .enable = armpmu_enable, - .disable = armpmu_disable, - .unthrottle = armpmu_unthrottle, - .read = armpmu_read, -}; - -void -hw_perf_enable (void ) +static void armpmu_pmu_enable (struct pmu *pmu) {/* Enable all of the perf events on hardware. */ int idx;
@@ -559,13 +550,22 @@ hw_perf_enable(void) armpmu->start (); } -void -hw_perf_disable (void ) +static void armpmu_pmu_disable (struct pmu *pmu) {if (armpmu) armpmu->stop (); } +static struct pmu pmu = { + .pmu_enable = armpmu_pmu_enable, + .pmu_disable= armpmu_pmu_disable, + .event_init = armpmu_event_init, + .enable = armpmu_enable, + .disable = armpmu_disable, + .unthrottle = armpmu_unthrottle, + .read = armpmu_read, +}; +/* * ARMv6 Performance counter handling code. *
arch/powerpc/kernel/perf_event.c +14 -12
@@ -517,7 +517,7 @@ static void write_mmcr0(struct cpu_hw_ev* Disable all events to prevent PMU interrupts and to allow * events to be added or removed. */ -void hw_perf_disable (void ) +static void powerpc_pmu_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuhw;unsigned long flags;
@@ -565,7 +565,7 @@ void hw_perf_disable(void)* If we were previously disabled and events were added, then * put the new config on the PMU. */ -void hw_perf_enable (void ) +static void powerpc_pmu_pmu_enable (struct pmu *pmu) {struct perf_event *event;struct cpu_hw_events *cpuhw;
@@ -735,7 +735,7 @@ static int power_pmu_enable(struct perf_int ret = -EAGAIN ;local_irq_save (flags); -perf_disable (); +perf_pmu_disable (event->pmu);/* * Add the event to the list (if there is room)
@@ -769,7 +769,7 @@ nocheck: ret =0 ; out: -perf_enable (); +perf_pmu_enable (event->pmu);local_irq_restore (flags);return ret; }
@@ -784,7 +784,7 @@ static void power_pmu_disable(struct perunsigned long flags;local_irq_save (flags); -perf_disable (); +perf_pmu_disable (event->pmu);power_pmu_read (event);
@@ -818,7 +818,7 @@ static void power_pmu_disable(struct per cpuhw->mmcr[0 ] &= ~(MMCR0_PMXE |MMCR0_FCECE ); } -perf_enable (); +perf_pmu_enable (event->pmu);local_irq_restore (flags); }
@@ -834,7 +834,7 @@ static void power_pmu_unthrottle(structif (!event->hw.idx || !event->hw.sample_period)return ;local_irq_save (flags); -perf_disable (); +perf_pmu_disable (event->pmu);power_pmu_read (event); left = event->hw.sample_period; event->hw.last_period = left;
@@ -845,7 +845,7 @@ static void power_pmu_unthrottle(structlocal64_set (&event->hw.prev_count, val);local64_set (&event->hw.period_left, left);perf_event_update_userpage (event); -perf_enable (); +perf_pmu_enable (event->pmu);local_irq_restore (flags); }
@@ -858,7 +858,7 @@ void power_pmu_start_txn(struct pmu *pmu {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); -perf_disable (); +perf_pmu_disable (pmu); cpuhw->group_flag |=PERF_EVENT_TXN ; cpuhw->n_txn_start = cpuhw->n_events; }
@@ -873,7 +873,7 @@ void power_pmu_cancel_txn(struct pmu *pmstruct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); cpuhw->group_flag &= ~PERF_EVENT_TXN ; -perf_enable (); +perf_pmu_enable (pmu); }/*
@@ -900,7 +900,7 @@ int power_pmu_commit_txn(struct pmu *pmu cpuhw->event[i]->hw.config = cpuhw->events[i]; cpuhw->group_flag &= ~PERF_EVENT_TXN ; -perf_enable (); +perf_pmu_enable (pmu);return 0 ; }
@@ -1128,7 +1128,9 @@ static int power_pmu_event_init(struct p }struct pmu power_pmu = { - .event_init = power_pmu_event_init, + .pmu_enable = power_pmu_pmu_enable, + .pmu_disable = power_pmu_pmu_disable, + .event_init = pmwer_pmu_event_init, .enable = power_pmu_enable, .disable = power_pmu_disable, .read = power_pmu_read,
arch/powerpc/kernel/perf_event_fsl_emb.c +10 -8
@@ -177,7 +177,7 @@ static void fsl_emb_pmu_read(struct perf* Disable all events to prevent PMU interrupts and to allow * events to be added or removed. */ -void hw_perf_disable (void ) +static void fsl_emb_pmu_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuhw;unsigned long flags;
@@ -216,7 +216,7 @@ void hw_perf_disable(void)* If we were previously disabled and events were added, then * put the new config on the PMU. */ -void hw_perf_enable (void ) +static void fsl_emb_pmu_pmu_enable (struct pmu *pmu) {struct cpu_hw_events *cpuhw;unsigned long flags;
@@ -271,7 +271,7 @@ static int fsl_emb_pmu_enable(struct peru64 val;int i; -perf_disable (); +perf_pmu_disable (event->pmu); cpuhw = &get_cpu_var (cpu_hw_events);if (event->hw.config &FSL_EMB_EVENT_RESTRICTED )
@@ -311,7 +311,7 @@ static int fsl_emb_pmu_enable(struct per ret =0 ; out:put_cpu_var (cpu_hw_events); -perf_enable (); +perf_pmu_enable (event->pmu);return ret; }
@@ -321,7 +321,7 @@ static void fsl_emb_pmu_disable(struct pstruct cpu_hw_events *cpuhw;int i = event->hw.idx; -perf_disable (); +perf_pmu_disable (event->pmu);if (i <0 ) goto out;
@@ -349,7 +349,7 @@ static void fsl_emb_pmu_disable(struct p cpuhw->n_events--; out: -perf_enable (); +perf_pmu_enable (event->pmu);put_cpu_var (cpu_hw_events); }
@@ -367,7 +367,7 @@ static void fsl_emb_pmu_unthrottle(strucif (event->hw.idx <0 || !event->hw.sample_period)return ;local_irq_save (flags); -perf_disable (); +perf_pmu_disable (event->pmu);fsl_emb_pmu_read (event); left = event->hw.sample_period; event->hw.last_period = left;
@@ -378,7 +378,7 @@ static void fsl_emb_pmu_unthrottle(strucatomic64_set (&event->hw.prev_count, val);atomic64_set (&event->hw.period_left, left);perf_event_update_userpage (event); -perf_enable (); +perf_pmu_enable (event->pmu);local_irq_restore (flags); }
@@ -524,6 +524,8 @@ static int fsl_emb_pmu_event_init(struct }static struct pmu fsl_emb_pmu = { + .pmu_enable = fsl_emb_pmu_pmu_enable, + .pmu_disable = fsl_emb_pmu_pmu_disable, .event_init = fsl_emb_pmu_event_init, .enable = fsl_emb_pmu_enable, .disable = fsl_emb_pmu_disable,
arch/sh/kernel/perf_event.c +18 -16
@@ -268,7 +268,25 @@ static in sh_pmu_event_init(struct perf_return err; } +static void sh_pmu_pmu_enable (struct pmu *pmu) +{ +if (!sh_pmu_initialized ()) +return ; + + sh_pmu->enable_all (); +} + +static void sh_pmu_pmu_disable (struct pmu *pmu) +{ +if (!sh_pmu_initialized ()) +return ; + + sh_pmu->disable_all (); +} +static struct pmu pmu = { + .pmu_enable = sh_pmu_pmu_enable, + .pmu_disable = sh_pmu_pmu_disable, .event_init = sh_pmu_event_init, .enable = sh_pmu_enable, .disable = sh_pmu_disable,
@@ -299,22 +317,6 @@ sh_pmu_notifier(struct notifier_block *sreturn NOTIFY_OK ; } -void hw_perf_enable (void ) -{ -if (!sh_pmu_initialized ()) -return ; - - sh_pmu->enable_all (); -} - -void hw_perf_disable (void ) -{ -if (!sh_pmu_initialized ()) -return ; - - sh_pmu->disable_all (); -} -int __cpuinit register_sh_pmu (struct sh_pmu *pmu) {if (sh_pmu)
arch/sparc/kernel/perf_event.c +11 -9
@@ -663,7 +663,7 @@ out:return pcr; } -void hw_perf_enable (void ) +static void sparc_pmu_pmu_enable (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);u64 pcr;
@@ -690,7 +690,7 @@ void hw_perf_enable(void) pcr_ops->write (cpuc->pcr); } -void hw_perf_disable (void ) +static void sparc_pmu_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);u64 val;
@@ -717,7 +717,7 @@ static void sparc_pmu_disable(struct perint i;local_irq_save (flags); -perf_disable (); +perf_pmu_disable (event->pmu);for (i =0 ; i < cpuc->n_events; i++) {if (event == cpuc->event[i]) {
@@ -747,7 +747,7 @@ static void sparc_pmu_disable(struct per } } -perf_enable (); +perf_pmu_enable (event->pmu);local_irq_restore (flags); }
@@ -990,7 +990,7 @@ static int sparc_pmu_enable(struct perf_unsigned long flags;local_irq_save (flags); -perf_disable (); +perf_pmu_disable (event->pmu); n0 = cpuc->n_events;if (n0 >= perf_max_events)
@@ -1019,7 +1019,7 @@ nocheck: ret =0 ; out: -perf_enable (); +perf_pmu_enable (event->pmu);local_irq_restore (flags);return ret; }
@@ -1112,7 +1112,7 @@ static void sparc_pmu_start_txn(struct p {struct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); -perf_disable (); +perf_pmu_disable (pmu); cpuhw->group_flag |=PERF_EVENT_TXN ; }
@@ -1126,7 +1126,7 @@ static void sparc_pmu_cancel_txn(structstruct cpu_hw_events *cpuhw = &__get_cpu_var (cpu_hw_events); cpuhw->group_flag &= ~PERF_EVENT_TXN ; -perf_enable (); +perf_pmu_enable (pmu); }/*
@@ -1150,11 +1150,13 @@ static int sparc_pmu_commit_txn(struct preturn -EAGAIN ; cpuc->group_flag &= ~PERF_EVENT_TXN ; -perf_enable (); +perf_pmu_enable (pmu);return 0 ; }static struct pmu pmu = { + .pmu_enable = sparc_pmu_pmu_enable, + .pmu_disable = sparc_pmu_pmu_disable, .event_init = sparc_pmu_event_init, .enable = sparc_pmu_enable, .disable = sparc_pmu_disable,
arch/x86/kernel/cpu/perf_event.c +9 -7
@@ -583,7 +583,7 @@ static void x86_pmu_disable_all(void) } } -void hw_perf_disable (void ) +static void x86_pmu_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);
@@ -803,7 +803,7 @@ static inline int match_prev_assignment(static int x86_pmu_start (struct perf_event *event);static void x86_pmu_stop (struct perf_event *event); -void hw_perf_enable (void ) +static void x86_pmu_pmu_enable (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);struct perf_event *event;
@@ -969,7 +969,7 @@ static int x86_pmu_enable(struct perf_ev hwc = &event->hw; -perf_disable (); +perf_pmu_disable (event->pmu); n0 = cpuc->n_events; ret = n =collect_events (cpuc, event, false);if (ret <0 )
@@ -999,7 +999,7 @@ done_collect: ret =0 ; out: -perf_enable (); +perf_pmu_enable (event->pmu);return ret; }
@@ -1403,7 +1403,7 @@ static void x86_pmu_start_txn(struct pmu {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events); -perf_disable (); +perf_pmu_disable (pmu); cpuc->group_flag |=PERF_EVENT_TXN ; cpuc->n_txn =0 ; }
@@ -1423,7 +1423,7 @@ static void x86_pmu_cancel_txn(struct pm*/ cpuc->n_added -= cpuc->n_txn; cpuc->n_events -= cpuc->n_txn; -perf_enable (); +perf_pmu_enable (pmu); }/*
@@ -1453,7 +1453,7 @@ static int x86_pmu_commit_txn(struct pmumemcpy (cpuc->assign, assign, n*sizeof (int )); cpuc->group_flag &= ~PERF_EVENT_TXN ; -perf_enable (); +perf_pmu_enable (pmu);return 0 ; }
@@ -1572,6 +1572,8 @@ int x86_pmu_event_init(struct perf_event }static struct pmu pmu = { + .pmu_enable = x86_pmu_pmu_enable, + .pmu_disable = x86_pmu_pmu_disable, .event_init = x86_pmu_event_init, .enable = x86_pmu_enable, .disable = x86_pmu_disable,
include/linux/perf_event.h +7 -6
@@ -561,6 +561,11 @@ struct perf_event;struct pmu {struct list_head entry; +int *pmu_disable_count; + +void (*pmu_enable) (struct pmu *pmu); +void (*pmu_disable) (struct pmu *pmu); +/* * Should return -ENOENT when the @event doesn't match this PMU. */
@@ -864,10 +869,8 @@ extern void perf_event_free_task(structextern void set_perf_event_pending (void );extern void perf_event_do_pending (void );extern void perf_event_print_debug (void ); -extern void __perf_disable (void ); -extern bool __perf_enable (void ); -extern void perf_disable (void ); -extern void perf_enable (void ); +extern void perf_pmu_disable (struct pmu *pmu); +extern void perf_pmu_enable (struct pmu *pmu);extern int perf_event_task_disable (void );extern int perf_event_task_enable (void );extern void perf_event_update_userpage (struct perf_event *event);
@@ -1038,8 +1041,6 @@ static inline void perf_event_exit_task(static inline void perf_event_free_task (struct task_struct *task) { }static inline void perf_event_do_pending (void ) { }static inline void perf_event_print_debug (void ) { } -static inline void perf_disable (void ) { } -static inline void perf_enable (void ) { }static inline int perf_event_task_disable (void ) {return -EINVAL ; }static inline int perf_event_task_enable (void ) {return -EINVAL ; }
kernel/perf_event.c +18 -12
@@ -71,23 +71,20 @@ static atomic64_t perf_event_id;*/ static DEFINE_SPINLOCK (perf_resource_lock); -void __weak hw_perf_disable (void ) {barrier (); } -void __weak hw_perf_enable (void ) {barrier (); } -void __weak perf_event_print_debug (void ) { } -static DEFINE_PER_CPU(int, perf_disable_count); - -void perf_disable (void ) +void perf_pmu_disable (struct pmu *pmu) { -if (!__get_cpu_var (perf_disable_count)++) -hw_perf_disable (); +int *count =this_cpu_ptr (pmu->pmu_disable_count); +if (!(*count)++) + pmu->pmu_disable (pmu); } -void perf_enable (void ) +void perf_pmu_enable (struct pmu *pmu) { -if (!--__get_cpu_var (perf_disable_count)) -hw_perf_enable (); +int *count =this_cpu_ptr (pmu->pmu_disable_count); +if (!--(*count)) + pmu->pmu_enable (pmu); }static void get_ctx (struct perf_event_context *ctx)
@@ -4760,16 +4757,25 @@ static struct srcu_struct pmus_srcu;int perf_pmu_register (struct pmu *pmu) { +int ret; +mutex_lock (&pmus_lock); + ret = -ENOMEM ; + pmu->pmu_disable_count =alloc_percpu (int); +if (!pmu->pmu_disable_count) + goto unlock;list_add_rcu (&pmu->entry, &pmus); + ret =0 ; +unlock:mutex_unlock (&pmus_lock); -return 0 ; +return ret; }void perf_pmu_unregister (struct pmu *pmu) {mutex_lock (&pmus_lock); +free_percpu (pmu->pmu_disable_count);list_del_rcu (&pmu->entry);mutex_unlock (&pmus_lock);
Re: [RFC][PATCH 08/11] perf: Per PMU disable
Quoted 1 line · Peter Zijlstra
Changes
perf_disable()intoperf_pmu_disable().
Needs this rolled in to compile on powerpc.
Paul.
arch/powerpc/kernel/perf_event.c +3 -3
@@ -517,7 +517,7 @@ static void write_mmcr0(struct cpu_hw_events *cpuhw, unsigned long mmcr0)* Disable all events to prevent PMU interrupts and to allow * events to be added or removed. */ -static void powerpc_pmu_pmu_disable (struct pmu *pmu) +static void power_pmu_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuhw;unsigned long flags;
@@ -565,7 +565,7 @@ static void powerpc_pmu_pmu_disable(struct pmu *pmu)* If we were previously disabled and events were added, then * put the new config on the PMU. */ -static void powerpc_pmu_pmu_enable (struct pmu *pmu) +static void power_pmu_pmu_enable (struct pmu *pmu) {struct perf_event *event;struct cpu_hw_events *cpuhw;
@@ -1130,7 +1130,7 @@ static int power_pmu_event_init(struct perf_event *event)struct pmu power_pmu = { .pmu_enable = power_pmu_pmu_enable, .pmu_disable = power_pmu_pmu_disable, - .event_init = pmwer_pmu_event_init, + .event_init = power_pmu_event_init, .enable = power_pmu_enable, .disable = power_pmu_disable, .read = power_pmu_read,
Peter Zijlstra
maintainerRe: [RFC][PATCH 08/11] perf: Per PMU disable
Quoted 5 lines · Paul Mackerras
Quoted 1 line · Peter Zijlstra
Changes
perf_disable()intoperf_pmu_disable().Needs this rolled in to compile on powerpc.
Done (a week or so ago, should have reposted, will do in a moment).
RFC PATCH 9/11 perf: Default PMU ops
In reply to Peter ZijlstraProvide default implementations for the pmu txn methods, this allows us to remove some conditional code.
--- kernel/perf_event.c | 48 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 12 deletions(-)
kernel/perf_event.c +36 -12
@@ -656,21 +656,14 @@ group_sched_in(struct perf_event *group_ {struct perf_event *event, *partial_group =NULL ;struct pmu *pmu = group_event->pmu; -bool txn = false;if (group_event->state ==PERF_EVENT_STATE_OFF )return 0 ; -/* Check if group transaction availabe */ -if (pmu->start_txn) - txn = true; - -if (txn) - pmu->start_txn (pmu); + pmu->start_txn (pmu);if (event_sched_in (group_event, cpuctx, ctx)) { -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }
@@ -684,7 +677,7 @@ group_sched_in(struct perf_event *group_ } } -if (!txn || !pmu->commit_txn (pmu)) +if (!pmu->commit_txn (pmu))return 0 ; group_error:
@@ -699,8 +692,7 @@ group_error: }event_sched_out (group_event, cpuctx, ctx); -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }
@@ -4755,6 +4747,26 @@ static struct list_head pmus;static DEFINE_MUTEX (pmus_lock);static struct srcu_struct pmus_srcu; +static void perf_pmu_nop (struct pmu *pmu) +{ +} + +static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +} + +static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ; +} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +} +int perf_pmu_register (struct pmu *pmu) {int ret;
@@ -4764,6 +4776,18 @@ int perf_pmu_register(struct pmu *pmu) pmu->pmu_disable_count =alloc_percpu (int);if (!pmu->pmu_disable_count) goto unlock; + +if (!pmu->pmu_enable) { + pmu->pmu_enable = perf_pmu_nop; + pmu->pmu_disable = perf_pmu_nop; + } + +if (!pmu->start_txn) { + pmu->start_txn = perf_pmu_start_txn; + pmu->commit_txn = perf_pmu_commit_txn; + pmu->cancel_txn = perf_pmu_cancel_txn; + } +list_add_rcu (&pmu->entry, &pmus); ret =0 ; unlock:
Re: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 67 lines · Peter Zijlstra
Provide default implementations for the pmu txn methods, this allows us to remove some conditional code.
Signed-off-by Peter Zijlstra <[email protected]>--- kernel/perf_event.c | 48 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 12 deletions(-)Index:
linux-2.6/kernel/perf_event.c
===================================================================kernel/perf_event.c +12
-12@@ -656,21 +656,14 @@ group_sched_in(struct perf_event *group_ {struct perf_event *event, *partial_group =NULL ;struct pmu *pmu = group_event->pmu; -bool txn = false;if (group_event->state ==PERF_EVENT_STATE_OFF )return 0 ; -/* Check if group transaction availabe */ -if (pmu->start_txn) - txn = true; - -if (txn) - pmu->start_txn (pmu); + pmu->start_txn (pmu);if (event_sched_in (group_event, cpuctx, ctx)) { -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -684,7 +677,7 @@ group_sched_in(struct perf_event *group_ } } -if (!txn || !pmu->commit_txn (pmu)) +if (!pmu->commit_txn (pmu))return 0 ; group_error:@@ -699,8 +692,7 @@ group_error: }event_sched_out (group_event, cpuctx, ctx); -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -4755,6 +4747,26 @@ static struct list_head pmus;static DEFINE_MUTEX (pmus_lock);static struct srcu_struct pmus_srcu; +static void perf_pmu_nop (struct pmu *pmu) +{ +} + +static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +}
kernel/perf_event.c static struct list_head pmus; · line 4767
Quoted 10 lines
kernel/perf_event.c +10
-0+ +static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ; +} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu);
Did you mean disable here?
Peter Zijlstra
maintainerRe: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 9 lines · Frederic Weisbecker
Quoted 9 lines
kernel/perf_event.c +9
-0+static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +} + +static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ;
Quoted 8 lines
kernel/perf_event.c static struct list_head pmus; · line 4767
Quoted 5 lines
kernel/perf_event.c +5
-0+} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu);Did you mean disable here?
Nope, start_txn() will disable the pmu, both commit_txn and cancel_txn can be used to close the transaction and should thus enable the pmu again.
Re: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 19 lines · Peter Zijlstra
Quoted 9 lines · Frederic Weisbecker
Quoted 9 lines
kernel/perf_event.c +9
-0+static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +} + +static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ;Quoted 8 lines
kernel/perf_event.c static struct list_head pmus; · line 4767
Quoted 5 lines
kernel/perf_event.c +5
-0+} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu);Did you mean disable here?
Quoted 3 lines
Nope,
start_txn()will disable the pmu, bothcommit_txnandcancel_txncan be used to close the transaction and should thus enable the pmu again.
Looks like I read that while walking on my arms, sorry.
Re: [RFC][PATCH 09/11] perf: Default PMU ops
In reply to Peter ZijlstraQuoted 68 lines · Peter Zijlstra
Provide default implementations for the pmu txn methods, this allows us to remove some conditional code.
Signed-off-by Peter Zijlstra <[email protected]>--- kernel/perf_event.c | 48 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 12 deletions(-)Index:
linux-2.6/kernel/perf_event.c
===================================================================kernel/perf_event.c +13
-12@@ -656,21 +656,14 @@ group_sched_in(struct perf_event *group_ {struct perf_event *event, *partial_group =NULL ;struct pmu *pmu = group_event->pmu; -bool txn = false;if (group_event->state ==PERF_EVENT_STATE_OFF )return 0 ; -/* Check if group transaction availabe */ -if (pmu->start_txn) - txn = true; - -if (txn) - pmu->start_txn (pmu); + pmu->start_txn (pmu);if (event_sched_in (group_event, cpuctx, ctx)) { -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -684,7 +677,7 @@ group_sched_in(struct perf_event *group_ } } -if (!txn || !pmu->commit_txn (pmu)) +if (!pmu->commit_txn (pmu))return 0 ; group_error:@@ -699,8 +692,7 @@ group_error: }event_sched_out (group_event, cpuctx, ctx); -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -4755,6 +4747,26 @@ static struct list_head pmus;static DEFINE_MUTEX (pmus_lock);static struct srcu_struct pmus_srcu; +static void perf_pmu_nop (struct pmu *pmu) +{ +} + +static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +} +
kernel/perf_event.c static struct list_head pmus; · line 4768
Quoted 10 lines
kernel/perf_event.c +10
-0+static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ; +} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +}
So why do you need perf_pmu_*able wrappers now that you brings stubs if none is provided?
Actually, one problem is that it makes calling two indirect nops for software events.
Should the txn things really map to the enable/disable ops is the off-case? Probably better let pmu implementations deal with that. If they didn't provide txn implementations, it means they don't need it, hence it should directly map to a nop.
Peter Zijlstra
maintainerRe: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 84 lines · Frederic Weisbecker
Quoted 68 lines · Peter Zijlstra
Provide default implementations for the pmu txn methods, this allows us to remove some conditional code.
Signed-off-by Peter Zijlstra <[email protected]>--- kernel/perf_event.c | 48 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 12 deletions(-)Index:
linux-2.6/kernel/perf_event.c
===================================================================kernel/perf_event.c +13
-12@@ -656,21 +656,14 @@ group_sched_in(struct perf_event *group_ {struct perf_event *event, *partial_group =NULL ;struct pmu *pmu = group_event->pmu; -bool txn = false;if (group_event->state ==PERF_EVENT_STATE_OFF )return 0 ; -/* Check if group transaction availabe */ -if (pmu->start_txn) - txn = true; - -if (txn) - pmu->start_txn (pmu); + pmu->start_txn (pmu);if (event_sched_in (group_event, cpuctx, ctx)) { -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -684,7 +677,7 @@ group_sched_in(struct perf_event *group_ } } -if (!txn || !pmu->commit_txn (pmu)) +if (!pmu->commit_txn (pmu))return 0 ; group_error:@@ -699,8 +692,7 @@ group_error: }event_sched_out (group_event, cpuctx, ctx); -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -4755,6 +4747,26 @@ static struct list_head pmus;static DEFINE_MUTEX (pmus_lock);static struct srcu_struct pmus_srcu; +static void perf_pmu_nop (struct pmu *pmu) +{ +} + +static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +} +kernel/perf_event.c static struct list_head pmus; · line 4768
Quoted 10 lines
kernel/perf_event.c +10
-0+static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ; +} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +}So why do you need perf_pmu_*able wrappers now that you brings stubs if none is provided?
Quoted 8 lines
Actually, one problem is that it makes calling two indirect nops for software events.
Should the txn things really map to the enable/disable ops is the off-case? Probably better let pmu implementations deal with that. If they didn't provide txn implementations, it means they don't need it, hence it should directly map to a nop.
You mean, if (!pmu->start_txn && pmu->pmu_enable) { /* install defaults */ } ?
Re: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 88 lines · Peter Zijlstra
Quoted 87 lines · Frederic Weisbecker
Quoted 68 lines · Peter Zijlstra
Provide default implementations for the pmu txn methods, this allows us to remove some conditional code.
Signed-off-by Peter Zijlstra <[email protected]>--- kernel/perf_event.c | 48 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 36 insertions(+), 12 deletions(-)Index:
linux-2.6/kernel/perf_event.c
===================================================================kernel/perf_event.c +13
-12@@ -656,21 +656,14 @@ group_sched_in(struct perf_event *group_ {struct perf_event *event, *partial_group =NULL ;struct pmu *pmu = group_event->pmu; -bool txn = false;if (group_event->state ==PERF_EVENT_STATE_OFF )return 0 ; -/* Check if group transaction availabe */ -if (pmu->start_txn) - txn = true; - -if (txn) - pmu->start_txn (pmu); + pmu->start_txn (pmu);if (event_sched_in (group_event, cpuctx, ctx)) { -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -684,7 +677,7 @@ group_sched_in(struct perf_event *group_ } } -if (!txn || !pmu->commit_txn (pmu)) +if (!pmu->commit_txn (pmu))return 0 ; group_error:@@ -699,8 +692,7 @@ group_error: }event_sched_out (group_event, cpuctx, ctx); -if (txn) - pmu->cancel_txn (pmu); + pmu->cancel_txn (pmu);return -EAGAIN ; }@@ -4755,6 +4747,26 @@ static struct list_head pmus;static DEFINE_MUTEX (pmus_lock);static struct srcu_struct pmus_srcu; +static void perf_pmu_nop (struct pmu *pmu) +{ +} + +static void perf_pmu_start_txn (struct pmu *pmu) +{ +perf_pmu_disable (pmu); +} +kernel/perf_event.c static struct list_head pmus; · line 4768
Quoted 10 lines
kernel/perf_event.c +10
-0+static int perf_pmu_commit_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +return 0 ; +} + +static void perf_pmu_cancel_txn (struct pmu *pmu) +{ +perf_pmu_enable (pmu); +}So why do you need perf_pmu_*able wrappers now that you brings stubs if none is provided?
Actually, one problem is that it makes calling two indirect nops for software events.
Quoted 8 lines
Quoted 5 lines
Should the txn things really map to the enable/disable ops is the off-case? Probably better let pmu implementations deal with that. If they didn't provide txn implementations, it means they don't need it, hence it should directly map to a nop.
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?
Not really. pmu_*able and txn are there for different purposes. A pmu implementation may want to provide enable/disable things but not require any txn. Or one may just not need any of those, like software events.
It should simply map to a nop if nothing is provided.
Peter Zijlstra
maintainerRe: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 10 lines · Frederic Weisbecker
Quoted 2 lines
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?Not really. pmu_*able and txn are there for different purposes. A pmu implementation may want to provide enable/disable things but not require any txn. Or one may just not need any of those, like software events.
It should simply map to a nop if nothing is provided.
Thing is, using at least the pmu_enable/disable fallback when no txn methods are provided can save bunch of hardware writes. So this trivial fallback makes sense.
Re: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 10 lines · Peter Zijlstra
Quoted 9 lines · Frederic Weisbecker
Quoted 2 lines
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?Not really. pmu_*able and txn are there for different purposes. A pmu implementation may want to provide enable/disable things but not require any txn. Or one may just not need any of those, like software events.
Quoted 5 lines
Quoted 1 line
It should simply map to a nop if nothing is provided.
Thing is, using at least the pmu_enable/disable fallback when no txn methods are provided can save bunch of hardware writes. So this trivial fallback makes sense.
In this case, archs should handle that by implementing their txn.
neglected pmu implementations shouldn't impact software pmus.
Peter Zijlstra
maintainerRe: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 6 lines · Frederic Weisbecker
Quoted 3 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker
Quoted 2 lines
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?neglected pmu implementations shouldn't impact software pmus.
With the above and not providing ->pmu_enable you get that.
Re: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 9 lines · Peter Zijlstra
Quoted 6 lines · Frederic Weisbecker
Quoted 3 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker
Quoted 2 lines
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?neglected pmu implementations shouldn't impact software pmus.
With the above and not providing ->pmu_enable you get that.
But we don't need to provide a pmu_enable for software events, right?
Peter Zijlstra
maintainerRe: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 7 lines · Frederic Weisbecker
Quoted 6 lines · Peter Zijlstra
Quoted 4 lines · Frederic Weisbecker
Quoted 3 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker
Quoted 2 lines
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
neglected pmu implementations shouldn't impact software pmus.
With the above and not providing ->pmu_enable you get that.
But we don't need to provide a
pmu_enablefor software events, right?
My point exactly.
Re: [RFC][PATCH 09/11] perf: Default PMU ops
Quoted 8 lines · Peter Zijlstra
Quoted 7 lines · Frederic Weisbecker
Quoted 6 lines · Peter Zijlstra
Quoted 4 lines · Frederic Weisbecker
Quoted 3 lines · Peter Zijlstra
Quoted 2 lines · Frederic Weisbecker
Quoted 2 lines
You mean, if (!pmu->start_txn &&
pmu->pmu_enable) { /* install defaults */ } ?
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
neglected pmu implementations shouldn't impact software pmus.
With the above and not providing ->pmu_enable you get that.
But we don't need to provide a
pmu_enablefor software events, right?My point exactly.
Which I understand late. Agreed.
RFC PATCH 10/11 perf: Shrink hw_perf_event
In reply to Peter ZijlstraUse hw_perf_event::period_left instead of hw_perf_event::remaning and win back 8 bytes.
--- include/linux/perf_event.h | 1 - kernel/perf_event.c | 13 ++++++------- 2 files changed, 6 insertions(+), 8 deletions(-)
include/linux/perf_event.h +0 -1
@@ -529,7 +529,6 @@ struct hw_perf_event {int last_cpu; };struct {/* software */ -s64 remaining;struct hrtimer hrtimer; };#ifdef CONFIG_HAVE_HW_BREAKPOINT
kernel/perf_event.c +6 -7
@@ -4590,14 +4590,13 @@ static void perf_swevent_start_hrtimer(shrtimer_init (&hwc->hrtimer,CLOCK_MONOTONIC ,HRTIMER_MODE_REL ); hwc->hrtimer.function = perf_swevent_hrtimer;if (hwc->sample_period) { -u64 period; +s64 period =local64_read (&hwc->period_left); -if (hwc->remaining) { -if (hwc->remaining <0 ) +if (period) { +if (period <0 ) period =10000 ; -else - period = hwc->remaining; - hwc->remaining =0 ; + +local64_set (&hwc->period_left,0 ); }else { period =max_t (u64,10000 , hwc->sample_period); }
@@ -4613,7 +4612,7 @@ static void perf_swevent_cancel_hrtimer(if (hwc->sample_period) {ktime_t remaining =hrtimer_get_remaining (&hwc->hrtimer); - hwc->remaining =ktime_to_ns (remaining); +local64_set (&hwc->period_left,ktime_to_ns (remaining));hrtimer_cancel (&hwc->hrtimer); }
Re: [RFC][PATCH 10/11] perf: Shrink hw_perf_event
Quoted 4 lines · Peter Zijlstra
Use
hw_perf_event::period_leftinstead ofhw_perf_event::remaningand win back 8 bytes.Signed-off-by Peter Zijlstra <[email protected]>
Quoted 52 lines
--- include/linux/perf_event.h | 1 - kernel/perf_event.c | 13 ++++++------- 2 files changed, 6 insertions(+), 8 deletions(-)Index:
linux-2.6/include/linux/perf_event.h
===================================================================include/linux/perf_event.h +0
-1@@ -529,7 +529,6 @@ struct hw_perf_event {int last_cpu; };struct {/* software */ -s64 remaining;struct hrtimer hrtimer; };#ifdef CONFIG_HAVE_HW_BREAKPOINT Index:
linux-2.6/kernel/perf_event.c
===================================================================kernel/perf_event.c +6
-7@@ -4590,14 +4590,13 @@ static void perf_swevent_start_hrtimer(shrtimer_init (&hwc->hrtimer,CLOCK_MONOTONIC ,HRTIMER_MODE_REL ); hwc->hrtimer.function = perf_swevent_hrtimer;if (hwc->sample_period) { -u64 period; +s64 period =local64_read (&hwc->period_left); -if (hwc->remaining) { -if (hwc->remaining <0 ) +if (period) { +if (period <0 ) period =10000 ; -else - period = hwc->remaining; - hwc->remaining =0 ; + +local64_set (&hwc->period_left,0 ); }else { period =max_t (u64,10000 , hwc->sample_period); }@@ -4613,7 +4612,7 @@ static void perf_swevent_cancel_hrtimer(if (hwc->sample_period) {ktime_t remaining =hrtimer_get_remaining (&hwc->hrtimer); - hwc->remaining =ktime_to_ns (remaining); +local64_set (&hwc->period_left,ktime_to_ns (remaining));hrtimer_cancel (&hwc->hrtimer); }
RFC PATCH 11/11 perf: Rework the PMU methods
In reply to Peter ZijlstraReplace pmu::{enable,disable,start,stop,unthrottle} with pmu::{add,del,start,stop}, all of which take a flags argument.
The new interface extends the capability to stop a counter while keeping it scheduled on the PMU. We replace the throttled state with the generic stopped state.
This also allows us to efficiently stop/start counters over certain code paths (like IRQ handlers).
It also allows scheduling a counter without it starting, allowing for a generic frozen state (useful for rotating stopped counters).
The stopped state is implemented in two different ways, depending on how the architecture implemented the throttled state:
1) We disable the counter:
a) the pmu has per-counter enable bits, we flip that
b) we program a NOP event, preserving the counter state
2) We store the counter state and ignore all read/overflow events
--- arch/arm/kernel/perf_event.c | 64 +++++++++---- arch/powerpc/kernel/perf_event.c | 107 ++++++++++++++-------- arch/powerpc/kernel/perf_event_fsl_emb.c | 113 ++++++++++++++---------- arch/sh/kernel/perf_event.c | 68 ++++++++++---- arch/sparc/kernel/perf_event.c | 109 ++++++++++++++--------- arch/x86/kernel/cpu/perf_event.c | 92 ++++++++++--------- arch/x86/kernel/cpu/perf_event_intel.c | 2 arch/x86/kernel/cpu/perf_event_intel_ds.c | 2 include/linux/ftrace_event.h | 4 include/linux/perf_event.h | 45 +++++++-- kernel/hw_breakpoint.c | 29 +++++- kernel/perf_event.c | 140 +++++++++++++++--------------- kernel/trace/trace_event_perf.c | 7 + 13 files changed, 489 insertions(+), 293 deletions(-)
arch/x86/kernel/cpu/perf_event.c +47 -45
@@ -583,7 +583,7 @@ static void x86_pmu_disable_all(void) } } -static void x86_pmu_pmu_disable (struct pmu *pmu) +static void x86_pmu_disable (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);
@@ -800,10 +800,10 @@ static inline int match_prev_assignment( hwc->last_tag == cpuc->tags[i]; } -static int x86_pmu_start (struct perf_event *event); -static void x86_pmu_stop (struct perf_event *event); +static void x86_pmu_start (struct perf_event *event,int flags); +static void x86_pmu_stop (struct perf_event *event,int flags); -static void x86_pmu_pmu_enable (struct pmu *pmu) +static void x86_pmu_enable (struct pmu *pmu) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);struct perf_event *event;
@@ -839,7 +839,7 @@ static void x86_pmu_pmu_enable(struct pm match_prev_assignment(hwc, cpuc, i))continue ; -x86_pmu_stop (event); +x86_pmu_stop (event,PERF_EF_UPDATE ); }for (i =0 ; i < cpuc->n_events; i++) {
@@ -851,7 +851,8 @@ static void x86_pmu_pmu_enable(struct pmelse if (i < n_running)continue ; -x86_pmu_start (event); +if (!(event->hw.state &PERF_HES_STOPPED )) +x86_pmu_start (event,PERF_EF_RELOAD ); } cpuc->n_added =0 ;perf_events_lapic_init ();
@@ -952,15 +953,12 @@ static void x86_pmu_enable_event(struct }/* -* activate a single event +* Add a single event to the PMU. * * The event is added to the group of enabled events * but only if it can be scehduled with existing events. -* -* Called with PMU disabled. If successful and return value 1, -* then guaranteed to call perf_enable() and hw_perf_enable() */ -static int x86_pmu_enable (struct perf_event *event) +static int x86_pmu_add (struct perf_event *event,int flags) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);struct hw_perf_event *hwc;
@@ -975,10 +973,14 @@ static int x86_pmu_enable(struct perf_evif (ret <0 ) goto out; + hwc->state =PERF_HES_UPTODATE ; +if (!(flags &PERF_EF_START )) + hwc->state |=PERF_HES_STOPPED ; +/* * If group events scheduling transaction was started, * skip the schedulability test here, it will be peformed -* at commit time(->commit_txn) as a whole +* at commit time (->commit_txn) as a whole */ if (cpuc->group_flag &PERF_EVENT_TXN ) goto done_collect;
@@ -1003,27 +1005,24 @@ out:return ret; } -static int x86_pmu_start (struct perf_event *event) +static void x86_pmu_start (struct perf_event *event,int flags) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);int idx = event->hw.idx; -if (idx ==-1 ) -return -EAGAIN ; +if (WARN_ON_ONCE (idx ==-1 )) +return ; + +if (flags &PERF_EF_RELOAD ) { +WARN_ON_ONCE (!(event->hw.state &PERF_HES_UPTODATE )); +x86_perf_event_set_period (event); + } -x86_perf_event_set_period (event); cpuc->events[idx] = event;__set_bit (idx, cpuc->active_mask); + event->hw.state =0 ; x86_pmu.enable (event);perf_event_update_userpage (event); - -return 0 ; -} - -static void x86_pmu_unthrottle (struct perf_event *event) -{ -int ret =x86_pmu_start (event); -WARN_ON_ONCE (ret); }void perf_event_print_debug (void )
@@ -1080,27 +1079,28 @@ void perf_event_print_debug(void)local_irq_restore (flags); } -static void x86_pmu_stop (struct perf_event *event) +static void x86_pmu_stop (struct perf_event *event,int flags) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);struct hw_perf_event *hwc = &event->hw; -int idx = hwc->idx; - -if (!__test_and_clear_bit (idx, cpuc->active_mask)) -return ; - - x86_pmu.disable (event); -/* -* Drain the remaining delta count out of a event -* that we are disabling: -*/ -x86_perf_event_update (event); +if (!__test_and_clear_bit (hwc->idx, cpuc->active_mask)) { + x86_pmu.disable (event); + cpuc->events[hwc->idx] =NULL ; + hwc->state |=PERF_HES_STOPPED ; + } - cpuc->events[idx] =NULL ; +if ((flags &PERF_EF_UPDATE ) && !(hwc->state &PERF_HES_UPTODATE )) { +/* +* Drain the remaining delta count out of a event +* that we are disabling: +*/ +x86_perf_event_update (event); + hwc->state |=PERF_HES_UPTODATE ; + } } -static void x86_pmu_disable (struct perf_event *event) +static void x86_pmu_del (struct perf_event *event,int flags) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);int i;
@@ -1113,7 +1113,7 @@ static void x86_pmu_disable(struct perf_if (cpuc->group_flag &PERF_EVENT_TXN )return ; -x86_pmu_stop (event); +x86_pmu_stop (event,PERF_EF_UPDATE );for (i =0 ; i < cpuc->n_events; i++) {if (event == cpuc->event_list[i]) {
@@ -1165,7 +1165,7 @@ static int x86_pmu_handle_irq(struct pt_continue ;if (perf_event_overflow (event,1 , &data, regs)) -x86_pmu_stop (event); +x86_pmu_stop (event,0 ); }if (handled)
@@ -1572,15 +1572,17 @@ int x86_pmu_event_init(struct perf_event }static struct pmu pmu = { - .pmu_enable = x86_pmu_pmu_enable, - .pmu_disable = x86_pmu_pmu_disable, + .pmu_enable = x86_pmu_enable, + .pmu_disable = x86_pmu_disable, + .event_init = x86_pmu_event_init, - .enable = x86_pmu_enable, - .disable = x86_pmu_disable, + + .add = x86_pmu_add, + .del = x86_pmu_del, .start = x86_pmu_start, .stop = x86_pmu_stop, .read = x86_pmu_read, - .unthrottle = x86_pmu_unthrottle, + .start_txn = x86_pmu_start_txn, .cancel_txn = x86_pmu_cancel_txn, .commit_txn = x86_pmu_commit_txn,
kernel/perf_event.c +72 -68
301 lines not on this page · raw message
kernel/trace/trace_event_perf.c +5 -2
@@ -107,7 +107,7 @@ int perf_trace_init(struct perf_event *preturn ret; } -int perf_trace_enable (struct perf_event *p_event) +int perf_trace_add (struct perf_event *p_event,int flags) {struct ftrace_event_call *tp_event = p_event->tp_event;struct hlist_head *list;
@@ -116,13 +116,16 @@ int perf_trace_enable(struct perf_eventif (WARN_ON_ONCE (!list))return -EINVAL ; +if (!(flags &PERF_EF_START )) + p_event->hw.state =PERF_HES_STOPPED ; + list =this_cpu_ptr (list);hlist_add_head_rcu (&p_event->hlist_entry, list);return 0 ; } -void perf_trace_disable (struct perf_event *p_event) +void perf_trace_del (struct perf_event *p_event,int flags) {hlist_del_rcu (&p_event->hlist_entry); }
arch/sh/kernel/perf_event.c +48 -20
119 lines not on this page · raw message
arch/arm/kernel/perf_event.c +46 -18
115 lines not on this page · raw message
arch/powerpc/kernel/perf_event.c +69 -38
190 lines not on this page · raw message
arch/powerpc/kernel/perf_event_fsl_emb.c +68 -45
188 lines not on this page · raw message
arch/sparc/kernel/perf_event.c +67 -42
184 lines not on this page · raw message
include/linux/ftrace_event.h +2 -2
@@ -245,8 +245,8 @@ DECLARE_PER_CPU(struct pt_regs, perf_traextern int perf_trace_init (struct perf_event *event);extern void perf_trace_destroy (struct perf_event *event); -extern int perf_trace_enable (struct perf_event *event); -extern void perf_trace_disable (struct perf_event *event); +extern int perf_trace_add (struct perf_event *event,int flags); +extern void perf_trace_del (struct perf_event *event,int flags);extern int ftrace_profile_set_filter (struct perf_event *event,int event_id,char *filter_str);extern void ftrace_profile_free_filter (struct perf_event *event);
include/linux/perf_event.h +36 -9
83 lines not on this page · raw message
arch/x86/kernel/cpu/perf_event_intel.c +1 -1
@@ -713,7 +713,7 @@ again: data.period = event->hw.last_period;if (perf_event_overflow (event,1 , &data, regs)) -x86_pmu_stop (event); +x86_pmu_stop (event,0 ); }intel_pmu_ack_status (ack);
arch/x86/kernel/cpu/perf_event_intel_ds.c +1 -1
@@ -491,7 +491,7 @@ static void __intel_pmu_pebs_event(struc regs.flags &= ~PERF_EFLAGS_EXACT ;if (perf_event_overflow (event,1 , &data, ®s)) -x86_pmu_stop (event); +x86_pmu_stop (event,0 ); }static void intel_pmu_drain_pebs_core (struct pt_regs *iregs)
kernel/hw_breakpoint.c +27 -2
@@ -570,10 +570,35 @@ static int hw_breakpoint_event_init(strureturn 0 ; } +static int hw_breakpoint_add (struct perf_event *bp,int flags) +{ +if (!(flags &PERF_EF_START )) + bp->hw.state =PERF_HES_STOPPED ; + +return arch_install_hw_breakpoint (bp); +} + +static void hw_breakpoint_del (struct perf_event *bp,int flags) +{ +arch_uninstall_hw_breakpoint (bp); +} + +static void hw_breakpoint_start (struct perf_event *bp,int flags) +{ + bp->hw.state =0 ; +} + +static void hw_breakpoint_stop (struct perf_event *bp,int flags) +{ + bp->hw.state =PERF_HES_STOPPED ; +} +static struct pmu perf_breakpoint = { .event_init = hw_breakpoint_event_init, - .enable = arch_install_hw_breakpoint, - .disable = arch_uninstall_hw_breakpoint, + .add = hw_breakpoint_add, + .del = hw_breakpoint_del, + .start = hw_breakpoint_start, + .stop = hw_breakpoint_stop, .read = hw_breakpoint_pmu_read, };
Re: [RFC][PATCH 11/11] perf: Rework the PMU methods
Quoted 16 lines · Peter Zijlstra
Replace pmu::{enable,disable,start,stop,unthrottle} with pmu::{add,del,start,stop}, all of which take a flags argument.
The new interface extends the capability to stop a counter while keeping it scheduled on the PMU. We replace the throttled state with the generic stopped state.
This also allows us to efficiently stop/start counters over certain code paths (like IRQ handlers).
It also allows scheduling a counter without it starting, allowing for a generic frozen state (useful for rotating stopped counters).
The stopped state is implemented in two different ways, depending on how the architecture implemented the throttled state:
Quoted 7 lines
1) We disable the counter:
a) the pmu has per-counter enable bits, we flip that
b) we program a NOP event, preserving the counter state2) We store the counter state and ignore all read/overflow events
Signed-off-by Peter Zijlstra <[email protected]>
Peter Zijlstra
maintainerRe: [RFC][PATCH 11/11] perf: Rework the PMU methods
Quoted 1 line · Frederic Weisbecker
I know it breaks at least x86 (although subtle, takes a few perf records to daze and confuse), arm and sh.
I need to get back to this patch-set and sort that :-)
Re: [RFC][PATCH 11/11] perf: Rework the PMU methods
Quoted 8 lines · Peter Zijlstra
Quoted 1 line · Frederic Weisbecker
I know it breaks at least x86 (although subtle, takes a few perf records to daze and confuse), arm and sh.
I need to get back to this patch-set and sort that :-)
Ok :)
But at least the whole idea looks good. Concerning the software parts I will make a second pass to optimize from my exclusion patchset, but other than that, it sets a nice background for it.
Hi Peter,
Quoted 7 lines · Peter Zijlstra
These patches prepare the perf code for multiple pmus (no user interface yet, Lin Ming is working on that). These patches remove all weak functions and rework the struct pmu interface.
The patches are boot tested on
x86_64and compile tested on: powerpc (!fsl, what config is that?), sparc and arm (sorry no SH compiler)
I tried to test these for ARM, but I get compilation errors. Maybe you forgot to enable perf in the ARM .config? Anyway, the compiler log is:
CC arch/arm/kernel/perf_event.oarch/arm/kernel/perf_event.c: In function 'validate_event':arch/arm/kernel/perf_event.c:342: error: 'pmu' undeclared (first use in this function) arch/arm/kernel/perf_event.c:342: error: (Each undeclared identifier is reported only once arch/arm/kernel/perf_event.c:342: error: for each function it appears in.) arch/arm/kernel/perf_event.c: In function 'armpmu_event_init':arch/arm/kernel/perf_event.c:536: warning: return makes integer from pointer without a cast arch/arm/kernel/perf_event.c: In function 'init_hw_perf_events':arch/arm/kernel/perf_event.c:3037: error: expected ';' before 'return' arch/arm/kernel/perf_event.c:3038: warning: no return statement in function returning non-void make[1]: *** [arch/arm/kernel/perf_event.o] Error 1
make: *** [arch/arm/kernel] Error 2
I think there's a missing semicolon, an ERR_PTR that should be a PTR_ERR and an ordering issue with the pmu struct.
Cheers,
Will
Peter Zijlstra
maintainerQuoted 27 lines · Will Deacon
Hi Peter,
Quoted 7 lines · Peter Zijlstra
These patches prepare the perf code for multiple pmus (no user interface yet, Lin Ming is working on that). These patches remove all weak functions and rework the struct pmu interface.
The patches are boot tested on
x86_64and compile tested on: powerpc (!fsl, what config is that?), sparc and arm (sorry no SH compiler)I tried to test these for ARM, but I get compilation errors. Maybe you forgot to enable perf in the ARM .config? Anyway, the compiler log is:
CC
arch/arm/kernel/perf_event.oarch/arm/kernel/perf_event.c: In function 'validate_event':arch/arm/kernel/perf_event.c:342: error: 'pmu' undeclared (first use in this function)arch/arm/kernel/perf_event.c:342: error: (Each undeclared identifier is reported only oncearch/arm/kernel/perf_event.c:342: error: for each function it appears in.)arch/arm/kernel/perf_event.c: In function 'armpmu_event_init':arch/arm/kernel/perf_event.c:536: warning: return makes integer from pointer without a castarch/arm/kernel/perf_event.c: In function 'init_hw_perf_events':arch/arm/kernel/perf_event.c:3037: error: expected ';' before 'return'arch/arm/kernel/perf_event.c:3038: warning: no return statement in function returning non-void make[1]: *** [arch/arm/kernel/perf_event.o] Error 1
make: *** [arch/arm/kernel] Error 2
Quoted 2 lines
I think there's a missing semicolon, an
ERR_PTRthat should be aPTR_ERRand an ordering issue with the pmu struct.
I seem to have lost a refresh before sending the emails, please check:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-perf.git perf-pmu
I pushed out updated patches there.
Hello,
Quoted 5 lines · Peter Zijlstra
I seem to have lost a refresh before sending the emails, please check:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-perf.gitperf-pmuI pushed out updated patches there.
Ok, I rebuilt my Kernel and perf tools from that tree and tested it on a quad-core ARMv7 board. Per-task counters appear to work (software and hardware) but pinned hardware counters always return 0:
root@will-lucid-nfs:~# perf stat -a -e cs -e cycles -e instructions -- ls linux-2.6 tmp
Performance counter stats for 'ls':
33 context-switches
0 cycles
0 instructions # 0.000 IPC 0.028572009 seconds time elapsed
It's odd if only ARM is affected in this way. Do pinned events still work for other people?
Will
Peter Zijlstra
maintainerQuoted 11 lines · Will Deacon
Hello,
Quoted 5 lines · Peter Zijlstra
I seem to have lost a refresh before sending the emails, please check:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-perf.gitperf-pmuI pushed out updated patches there.
Ok, I rebuilt my Kernel and perf tools from that tree and tested it on a quad-core ARMv7 board.
Ooh, neat toy ;-)
Quoted 13 lines
Per-task counters appear to work (software and hardware) but pinned hardware counters always return 0:
root@will-lucid-nfs:~# perf stat -a -e cs -e cycles -e instructions -- ls linux-2.6 tmpPerformance counter stats for 'ls':
33 context-switches 0 cycles 0 instructions # 0.000 IPC
Quoted 5 lines
0.028572009 seconds time elapsedIt's odd if only ARM is affected in this way. Do pinned events still work for other people?
/me goes build that exact tree on his x86_64.. and gets:
# perf stat -a -e cs -e cycles -e instructions -- ls > /dev/null
Performance counter stats for 'ls':
51 context-switches
24963513 cycles
9225808 instructions # 0.370 IPC 0.002389051 seconds time elapsed
Not exactly sure how I could have messed up the ARM architecture code to make this happen though... will have a peek.
Peter Zijlstra
maintainerQuoted 2 lines · Peter Zijlstra
Not exactly sure how I could have messed up the ARM architecture code to make this happen though... will have a peek.
I did find a bug in there, not sure it could have been responsible for this but who knows...
Pushed out a new git tree with the below delta folded in.
---
arch/arm/kernel/perf_event.c +21 -23
@@ -221,27 +221,6 @@ again: }static void -armpmu_del (struct perf_event *event,int flags) -{ -struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events); -struct hw_perf_event *hwc = &event->hw; -int idx = hwc->idx; - -WARN_ON (idx <0 ); - -clear_bit (idx, cpuc->active_mask); - armpmu->disable (hwc, idx); - -barrier (); - -armpmu_event_update (event, hwc, idx); - cpuc->events[idx] =NULL ; -clear_bit (idx, cpuc->used_mask); - -perf_event_update_userpage (event); -} - -static void armpmu_read (struct perf_event *event) {struct hw_perf_event *hwc = &event->hw;
@@ -267,6 +246,8 @@ armpmu_stop(struct perf_event *event, in*/ if (!(hwc->state &PERF_HES_STOPPED )) { armpmu->disable (hwc, hwc->idx); +barrier ();/* why? */ +armpmu_event_update (event, hwc, hwc->idx); hwc->state |=PERF_HES_STOPPED |PERF_HES_UPTODATE ; } }
@@ -289,7 +270,7 @@ armpmu_start(struct perf_event *event, i hwc->state =0 ;/* * Set the period again. Some counters can't be stopped, so when we -* were throttled we simply disabled the IRQ source and the counter +* were stopped we simply disabled the IRQ source and the counter * may have been left counting. If we don't do this step then we may * get an interrupt too soon or *way* too late if the overflow has * happened since disabling.
@@ -298,6 +279,23 @@ armpmu_start(struct perf_event *event, i armpmu->enable (hwc, hwc->idx); } +static void +armpmu_del (struct perf_event *event,int flags) +{ +struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events); +struct hw_perf_event *hwc = &event->hw; +int idx = hwc->idx; + +WARN_ON (idx <0 ); + +clear_bit (idx, cpuc->active_mask); +armpmu_stop (event,PERF_EF_UPDATE ); + cpuc->events[idx] =NULL ; +clear_bit (idx, cpuc->used_mask); + +perf_event_update_userpage (event); +} +static int armpmu_add (struct perf_event *event,int flags) {
@@ -1075,7 +1073,7 @@ armv6pmu_handle_irq(int irq_num,continue ;if (perf_event_overflow (event,0 , &data, regs)) -armpmu_stop (event,0 ); + armpmu->disable (hwc, idx); }/*
Peter Zijlstra
maintainerQuoted 3 lines · Peter Zijlstra
Pushed out a new git tree with the below delta folded in.
Said tree also cures x86 and folds the SH build fix.
Matt, you said it broke SH completely, but did you try perf stat? perf record is not supposed to work on SH due to the hardware not having an overflow interrupt.
Which made me think, what on SH guarantees we update the counter often enough not to suffer from counter wrap? Would it make sense to make the SH code hook into their arch tick handler and update the counters from there?
Quoted 4 lines · Peter Zijlstra
Matt, you said it broke SH completely, but did you try perf stat? perf record is not supposed to work on SH due to the hardware not having an overflow interrupt.
perf record does work to some degree. It definitely worked before applying your changes but not after. I admit I haven't really read the perf event code, but Paul will know.
Quoted 4 lines
Which made me think, what on SH guarantees we update the counter often enough not to suffer from counter wrap? Would it make sense to make the SH code hook into their arch tick handler and update the counters from there?
This was the way that the oprofile code used to work. Paul and I were talking about using a hrtimer to sample performance counters as opposed to piggy-backing on the tick handler.
Peter Zijlstra
maintainerQuoted 9 lines · MattFleming
Quoted 4 lines · Peter Zijlstra
Matt, you said it broke SH completely, but did you try perf stat? perf record is not supposed to work on SH due to the hardware not having an overflow interrupt.
perf record does work to some degree. It definitely worked before applying your changes but not after. I admit I haven't really read the perf event code, but Paul will know.
Ok, let me look at that again.
Quoted 8 lines
Quoted 4 lines
Which made me think, what on SH guarantees we update the counter often enough not to suffer from counter wrap? Would it make sense to make the SH code hook into their arch tick handler and update the counters from there?
This was the way that the oprofile code used to work. Paul and I were talking about using a hrtimer to sample performance counters as opposed to piggy-backing on the tick handler.
Ah, for sampling for sure, simply group a software perf event and a hardware perf event together and use PERF_SAMPLE_READ.
But suppose its a non sampling counter, how do you avoid overflows of the hardware register?
Quoted 12 lines · Peter Zijlstra
Quoted 10 lines · MattFleming
Quoted 5 lines · Peter Zijlstra
Which made me think, what on SH guarantees we update the counter often enough not to suffer from counter wrap? Would it make sense to make the SH code hook into their arch tick handler and update the counters from there?
This was the way that the oprofile code used to work. Paul and I were talking about using a hrtimer to sample performance counters as opposed to piggy-backing on the tick handler.
Quoted 5 lines
Ah, for sampling for sure, simply group a software perf event and a hardware perf event together and use
PERF_SAMPLE_READ.But suppose its a non sampling counter, how do you avoid overflows of the hardware register?
Hmm.. good question! I'm not entirely sure we do. As you were saying, without using the arch tick handler, I don't think we can guarantee avoiding counter overflows. Currently the counters are chained such that the counters are at least 48 bits. I guess all my tests were short enough to not cause the counters to wrap ;-)
At some point we will want to not require chaining, giving us 32 bits. So yeah, this is issue is gonna crop up then. Interestingly, the counters on SH don't wrap when they reach they're maximum value, they just stop incrementing.
Quoted 7 lines · Peter Zijlstra
Quoted 6 lines · MattFleming
Quoted 4 lines · Peter Zijlstra
Matt, you said it broke SH completely, but did you try perf stat? perf record is not supposed to work on SH due to the hardware not having an overflow interrupt.
Quoted 6 lines
Quoted 3 lines
perf record does work to some degree. It definitely worked before applying your changes but not after. I admit I haven't really read the perf event code, but Paul will know.
Ok, let me look at that again.
Any perf record functionality observed is entirely coincidental and not by design. It was something I planned to revisit, but most of what we have right now is only geared at the one-shot perf stat case.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
Which made me think, what on SH guarantees we update the counter often enough not to suffer from counter wrap? Would it make sense to make the SH code hook into their arch tick handler and update the counters from there?
This was the way that the oprofile code used to work. Paul and I were talking about using a hrtimer to sample performance counters as opposed to piggy-backing on the tick handler.
Quoted 5 lines
Ah, for sampling for sure, simply group a software perf event and a hardware perf event together and use
PERF_SAMPLE_READ.But suppose its a non sampling counter, how do you avoid overflows of the hardware register?
At the moment it's not an issue since we have big enough counters that overflows don't really happen, especially if we're primarily using them for one-shot measuring.
SH-4A style counters behave in such a fashion that we have 2 general purpose counters, and 2 counters for measuring bus transactions. These bus counters can optionally be disabled and used in a chained mode to provide the general purpose counters a 64-bit counter (the actual validity in the upper half of the chained counter varies depending on the CPUs, but all of them can do at least 48-bits when chained).
Each counter has overflow detection and asserts an overflow bit, but there are no exceptions associated with this, so it's something that we would have to tie in to the tick or defer to a bottom half handler in the non-sampling case (or simply test on every read, and accept some degree of accuracy loss). Any perf record functionality we implement with this sort of scheme is only going to provide ballpark figures anyways, so it's certainly within the parameters of acceptable loss in exchange for increased functionality.
Different CPUs also implement their overflows differently, some will roll and resume counting, but most simply stop until the overflow bit is cleared.
My main plan was to build on top of the multi-pmu stuff, unchain the counters, and expose the bus counters with their own event map as a separate PMU instance. All of the other handling logic can pretty much be reused directly, but it does mean that we need to be a bit smarter about overflow detection/handling. Sampling and so on is also on the TODO list, but is as of yet still not supported.
Peter Zijlstra
maintainerQuoted 10 lines · Paul Mundt
At the moment it's not an issue since we have big enough counters that overflows don't really happen, especially if we're primarily using them for one-shot measuring.
SH-4A style counters behave in such a fashion that we have 2 general purpose counters, and 2 counters for measuring bus transactions. These bus counters can optionally be disabled and used in a chained mode to provide the general purpose counters a 64-bit counter (the actual validity in the upper half of the chained counter varies depending on the CPUs, but all of them can do at least 48-bits when chained).
Right, so I was reading some of that code and I couldn't actually find where you keep consistency between the hardware counter value and the stored prev_count value.
That is, suppose I'm counting, the hardware starts at 0, hwc->prev_count = 0 and event->count = 0.
At some point, x we context switch this task away, so we ->disable(), which disables the counter and updates the values, so at that time hwc->prev = x and event->count = x, right?
Now suppose we schedule the task back in, so we do ->enable(), then what happens? sh_pmu_enable() finds an unused index, (disables it for some reason.. it should already be cleared if its not used, but I guess a few extra hardware writes dont hurt) and calls sh4a_pmu_enable() on it.
sh4a_pmu_enable() does 3 writes:
PPC_PMCAT -- does this clear the counter value? PPC_CCBR -- writes the ->config bits PPC_CCBR (adds CCBR_DUC, couldn't this be done in the
previous write to this reg?)
Now assuming that enable does indeed clear the hardware counter value, shouldn't you also set hwc->prev_count to 0 again? Otherwise the next update will see a massive jump?
Alternatively you could write the hwc->prev_count value back to the register.
If you eventually want to drop the chained counter support I guess it would make sense to have sh_perf_event_update() read and clear the counter so that you're always 0 based and then enforce an update from the arch tick hander so you never overflow.
Quoted 7 lines · Peter Zijlstra
Right, so I was reading some of that code and I couldn't actually find where you keep consistency between the hardware counter value and the stored
prev_countvalue.That is, suppose I'm counting, the hardware starts at 0,
hwc->prev_count= 0 andevent->count= 0.
Quoted 9 lines
At some point, x we context switch this task away, so we ->disable(), which disables the counter and updates the values, so at that time
hwc->prev= x andevent->count= x, right?Now suppose we schedule the task back in, so we do ->enable(), then what happens?
sh_pmu_enable()finds an unused index, (disables it for some reason.. it should already be cleared if its not used, but I guess a few extra hardware writes dont hurt) and callssh4a_pmu_enable()on it.
I don't quite remember where the ->disable() came from, I vaguely recall copying it from one of the other architectures, but it could have just been a remnant of something I had for debug code. In any event, you're correct, we don't seem to need it anymore.
Quoted 3 lines
sh4a_pmu_enable()does 3 writes:
PPC_PMCAT-- does this clear the counter value?
Yes, the counters themselves are read-only, so clearing is done through the PMCAT control register.
Quoted 4 lines
PPC_CCBR-- writes the ->config bitsPPC_CCBR(addsCCBR_DUC, couldn't this be done in the
previous write to this reg?)
No, the DUC bit needs to be set by itself or the write is discarded on some CPUs. Clearing it with other bits is fine, however. This is what starts the counter running.
Quoted 4 lines
Now assuming that enable does indeed clear the hardware counter value, shouldn't you also set
hwc->prev_countto 0 again? Otherwise the next update will see a massive jump?
I think that's a correct observation, but I'm having difficulty verifying it on my current board since it seems someone moved the PMCAT register, as the counters aren't being cleared on this particular CPU. I'll test on the board I wrote this code for initially tomorrow and see how that goes. It did used to work fine at least.
Quoted 3 lines
Alternatively you could write the
hwc->prev_countvalue back to the register.
That would be an option if the counters weren't read-only, yes.
Quoted 5 lines
If you eventually want to drop the chained counter support I guess it would make sense to have
sh_perf_event_update()read and clear the counter so that you're always 0 based and then enforce an update from the arch tick hander so you never overflow.
Yes, I'd thought about that too. I'll give it a go once I find out where the other half of my registers disappeared to. As it is, it seems my bat and I have an appointment to make.
Peter Zijlstra
maintainerQuoted 3 lines · Peter Zijlstra
Ah, for sampling for sure, simply group a software perf event and a hardware perf event together and use
PERF_SAMPLE_READ.
So the idea is to sample using a software event (periodic timer of sorts, maybe randomize it) and weight its samples by the hardware event deltas.
Suppose you have a workload consisting of two main parts:
my_important_work()
{
load_my_data();
compute_me_silly();
}Now, lets assume that both these functions take the same time to complete for each part of work. In that case a periodic timer generate samples that are about 50/50 distributed between these two functions.
Now, let us further assume that load_my_data() is so slow because its missing all the caches and compute_me_silly() is slow because its defeating the branch predictor.
So what we want to end up with, is that when we sample for cache-misses we get load_my_data() as the predominant function, not a nice 50/50 relation. Idem for branch misses and compute_me_silly().
By weighting the samples by the hw counter delta we get this, if we assume that the sampling frequency is not a harmonic of the runtime of these functions, then statistics will dtrt.
It basically generates a massive skid on the sample, but as long as most of the samples end up hitting the right function we're good. For a periodic workload like:
while (lots) { my_important_work() }
that is even true for period > function_runtime with the exception of that harmonic thing. For less neat workloads like:
while (lots) { my_important_work(); other_random_things(); }
This doesn't need to work unless period < function_runtime.
Clearly we cannot attribute anything to the actual instruction hit due to the massive skid, but we can (possibly) say something about the function based on these statistical rules.
Quoted 24 lines · Peter Zijlstra
Quoted 3 lines · Peter Zijlstra
Ah, for sampling for sure, simply group a software perf event and a hardware perf event together and use
PERF_SAMPLE_READ.So the idea is to sample using a software event (periodic timer of sorts, maybe randomize it) and weight its samples by the hardware event deltas.
Suppose you have a workload consisting of two main parts:
my_important_work() { load_my_data(); compute_me_silly(); }Now, lets assume that both these functions take the same time to complete for each part of work. In that case a periodic timer generate samples that are about 50/50 distributed between these two functions.
Now, let us further assume that
load_my_data()is so slow because its missing all the caches andcompute_me_silly()is slow because its defeating the branch predictor.
Quoted 7 lines
So what we want to end up with, is that when we sample for cache-misses we get
load_my_data()as the predominant function, not a nice 50/50 relation. Idem for branch misses andcompute_me_silly().By weighting the samples by the hw counter delta we get this, if we assume that the sampling frequency is not a harmonic of the runtime of these functions, then statistics will dtrt.
Yes.
And if the platform code implements this then the tooling side already takes care of it - even if the CPU itself cannot geneate interrupts based on say cachemisses or branches (but can measure them via counts).
The only situation where statistics will not do the right thing is when the likelyhood of the sample tick significantly correlates with the likelyhood of the workload itself executing. Timer-dominated workloads would be an example.
Real hrtimers are sufficiently tick-less to solve most of these artifacts in practice.
Ingo
Quoted 4 lines · Ingo Molnar
And if the platform code implements this then the tooling side already takes care of it - even if the CPU itself cannot geneate interrupts based on say cachemisses or branches (but can measure them via counts).
I finally got a bit of time to work on this. I'm confused about how the tools will take care of this at the moment. How much support currently exists for these sorts of weighted samples? The only thing I can find that looks related is PERF_SAMPLE_READ, but I don't think that's exactly what we need.
Could someone point me in the right direction?
Hi Peter,
Quoted 10 lines · Peter Zijlstra
Quoted 2 lines · Peter Zijlstra
Not exactly sure how I could have messed up the ARM architecture code to make this happen though... will have a peek.
I did find a bug in there, not sure it could have been responsible for this but who knows...
Pushed out a new git tree with the below delta folded in.
I had a look at this yesterday and discovered a bug in the ARM backend code, which I've posted a patch for to ALKML:
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-July/019461.html
Unfortunately, with this applied and your latest changes I still get 0 from pinned hardware counters:
# perf stat -r 5 -e cycles -e instructions -e cs -e faults -e branches -a -- git status
Performance counter stats for 'git status' (5 runs):
0 cycles ( +- nan% )
0 instructions # 0.000 IPC ( +- nan% )
88447 context-switches ( +- 12.624% )
13647 page-faults ( +- 0.015% )
0 branches ( +- nan% )The changes you've made to arch/arm/kernel/perf_event.c look sane. If I get some time I'll try and dig deeper.
Will
Quoted 6 lines · Peter Zijlstra
These patches prepare the perf code for multiple pmus (no user interface yet, Lin Ming is working on that). These patches remove all weak functions and rework the struct pmu interface.
The patches are boot tested on
x86_64and compile tested on: powerpc (!fsl, what config is that?), sparc and arm (sorry no SH compiler)
Hi Peter,
I tried your SH changes and I needed to apply this patch to get it to compile. I haven't run the code yet, but I'll do that later today.
---
arch/sh/kernel/perf_event.c +6 -6
@@ -251,7 +251,7 @@ static void sh_pmu_del(struct perf_event *event, int flags)perf_event_update_userpage (event); } -static int sh_pmu_enable (struct perf_event *event,int flags) +static int sh_pmu_add (struct perf_event *event,int flags) {struct cpu_hw_events *cpuc = &__get_cpu_var (cpu_hw_events);struct hw_perf_event *hwc = &event->hw;
@@ -283,7 +283,7 @@ static void sh_pmu_read(struct perf_event *event)sh_perf_event_update (event, &event->hw, event->hw.idx); } -static in sh_pmu_event_init (struct perf_event *event) +static int sh_pmu_event_init (struct perf_event *event) {int err =__hw_perf_event_init (event);if (unlikely (err)) {
@@ -345,15 +345,15 @@ sh_pmu_notifier(struct notifier_block *self, unsigned long action, void *hcpu)return NOTIFY_OK ; } -int __cpuinit register_sh_pmu (struct sh_pmu *pmu) +int __cpuinit register_sh_pmu (struct sh_pmu *_pmu) {if (sh_pmu)return -EBUSY ; - sh_pmu = pmu; + sh_pmu = _pmu; -pr_info ("Performance Events: %s support registered\n" , pmu->name); +pr_info ("Performance Events: %s support registered\n" , _pmu->name); -WARN_ON (pmu->num_events >MAX_HWEVENTS ); +WARN_ON (_pmu->num_events >MAX_HWEVENTS );perf_pmu_register (&pmu);perf_cpu_notifier (sh_pmu_notifier);
Quoted 7 lines · Peter Zijlstra
These patches prepare the perf code for multiple pmus (no user interface yet, Lin Ming is working on that). These patches remove all weak functions and rework the struct pmu interface.
The patches are boot tested on
x86_64and compile tested on: powerpc (!fsl, what config is that?), sparc and arm (sorry no SH compiler)
Quoted 7 lines
On x86 perf stat and record with both software and hardware events still worked.
I changed all (hardware) pmu implementations so there's a fair chance I messed something up, please have a look at it.
If people agree with this, I'll continue with the per-pmu context stuff I talked about last time, which should get us the hardware write batching back.
Hi Peter,
These patches look like they are really taking us in the right direction. Thanks for all your effort on this!
As for the "hardware write batching", can you describe a bit more about what you have in mind there? I wonder if this might have something to do with accounting for PMU hardware which is slow to access, for example, via I2C via an internal bridge.
Cheers,
- Corey
Peter Zijlstra
maintainerQuoted 2 lines · Corey Ashford
These patches look like they are really taking us in the right direction. Thanks for all your effort on this!
Yeah, although I seem to have managed to wreck all architectures tested so far (I found some iffy on x86 too), I guess I need to carefully look at things.
Quoted 4 lines
As for the "hardware write batching", can you describe a bit more about what you have in mind there? I wonder if this might have something to do with accounting for PMU hardware which is slow to access, for example, via I2C via an internal bridge.
Right, so the write batching is basically delaying writing out the PMU state to hardware until pmu::pmu_enable() time. It avoids having to re-program the hardware when, due to a scheduling constraint, we have to move counters around.
So say, we context switch a task, and remove the old events and add the new ones under a single pmu::pmu_disable()/::pmu_enable() pair, we will only hit the hardware twice (once to disable, once to enable), instead of for each individual ::del()/::add().
For this to work we need to have an association between a context and a pmu, otherwise its very hard to know what pmu to disable/enable; the alternative is all of them which isn't very attractive.
Then again, it doesn't make sense to have task-counters on an I2C attached PMU simply because writing to the PMU could cause context switches.
Quoted 16 lines · Peter Zijlstra
On Sat, 2010-06-26 at 09:22 -0700, Corey Ashford wrote:
As for the "hardware write batching", can you describe a bit more aboutQuoted 3 lines
what you have in mind there? I wonder if this might have something to do with accounting for PMU hardware which is slow to access, for example, via I2C via an internal bridge.
Right, so the write batching is basically delaying writing out the PMU state to hardware until
pmu::pmu_enable()time. It avoids having to re-program the hardware when, due to a scheduling constraint, we have to move counters around.So say, we context switch a task, and remove the old events and add the new ones under a single pmu::pmu_disable()/::pmu_enable() pair, we will only hit the hardware twice (once to disable, once to enable), instead of for each individual ::del()/::add().
Quoted 7 lines
For this to work we need to have an association between a context and a pmu, otherwise its very hard to know what pmu to disable/enable; the alternative is all of them which isn't very attractive.
Then again, it doesn't make sense to have task-counters on an I2C attached PMU simply because writing to the PMU could cause context switches.
Thanks for your reply.
In our case, writing to some of the nest PMUs' control registers is done via an internal bridge. We write to a specific memory address and an internal MMIO-to-SCOM bridge (SCOM is similar to I2C) translates it to serial and sends it over the internal serial bus. The address we write to is based upon the control register's serial bus address, plus an offset from the base of MMIO-to-SCOM bridge. The same process works for reads.
While it does not cause a context switch because there are no IO drivers to go through, it will take several thousand CPU cycles to complete, which by the same token, still makes them inappropriate for task-counters (not to mention that the nest units operate asynchronously from the CPU).
However, there still are concerns relative to writing these control registers from an interrupt handler because of the latency that will be incurred, however slow we choose to do the event rotation. So at least for the Wire-Speed processor, we may need a worker thread of some sort to hand off the work to.
Our current code, based on linux 2.6.31 (soon to be 2.6.32) doesn't use worker threads; we are just taking the latency hit for now.
- Corey
Peter Zijlstra
maintainerQuoted 5 lines · Corey Ashford
However, there still are concerns relative to writing these control registers from an interrupt handler because of the latency that will be incurred, however slow we choose to do the event rotation. So at least for the Wire-Speed processor, we may need a worker thread of some sort to hand off the work to.
Right, once we have per-pmu contexts we can look at having means to over-ride the means of rotation, such that the pmu can optionally drive it itself instead of through the common tick.