* [PATCH] arm: perf: Add event descriptions
@ 2015-08-04 0:15 ` Drew Richardson
0 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-08-04 0:15 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Will Deacon, Russell King, linux-kernel, linux-arm-kernel
Cc: Wade Cherry
Add additional information about hardware events to make counters self
describing. This makes the hardware PMUs easier to use as perf list
contains the possible events instead of users having to refer to
documentation like the ARM TRMs. This could also allow tools like
oprofile to support PMUs without requiring an update.
Signed-off-by: Drew Richardson <drew.richardson@arm.com>
---
arch/arm/kernel/perf_event.c | 1 +
arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 618 insertions(+)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 54272e0be713..a7f2c84bae15 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -548,6 +548,7 @@ static void armpmu_init(struct arm_pmu *armpmu)
.stop = armpmu_stop,
.read = armpmu_read,
.filter_match = armpmu_filter_match,
+ .attr_groups = armpmu->pmu.attr_groups,
};
}
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index f9b37f876e20..d46bc78b5997 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -547,6 +547,616 @@ static const unsigned scorpion_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
[C(BPU)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
};
+static ssize_t armv7_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_ext_attribute *ea = container_of(attr,
+ struct dev_ext_attribute,
+ attr);
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", (char *)ea->var);
+}
+
+#define ARMV7_EVENT_ATTR(config, name) \
+ struct dev_ext_attribute armv7_event_attr_##config##_##name = \
+ { __ATTR(name, S_IRUGO, armv7_event_show, NULL), \
+ "config=0x" #config }
+
+static ARMV7_EVENT_ATTR(00, sw_incr);
+static ARMV7_EVENT_ATTR(01, l1i_cache_refill);
+static ARMV7_EVENT_ATTR(02, l1i_tlb_refill);
+static ARMV7_EVENT_ATTR(03, l1d_cache_refill);
+static ARMV7_EVENT_ATTR(04, l1d_cache);
+static ARMV7_EVENT_ATTR(05, l1d_tlb_refill);
+static ARMV7_EVENT_ATTR(06, ld_retired);
+static ARMV7_EVENT_ATTR(07, st_retired);
+static ARMV7_EVENT_ATTR(08, inst_retired);
+static ARMV7_EVENT_ATTR(09, exc_taken);
+static ARMV7_EVENT_ATTR(0a, exc_return);
+static ARMV7_EVENT_ATTR(0b, cid_write_retired);
+static ARMV7_EVENT_ATTR(0c, pc_write_retired);
+static ARMV7_EVENT_ATTR(0d, br_immed_retired);
+static ARMV7_EVENT_ATTR(0e, br_return_retired);
+static ARMV7_EVENT_ATTR(0f, unaligned_ldst_retired);
+static ARMV7_EVENT_ATTR(10, br_mis_pred);
+static ARMV7_EVENT_ATTR(11, cpu_cycles);
+static ARMV7_EVENT_ATTR(12, br_pred);
+static ARMV7_EVENT_ATTR(13, mem_access);
+static ARMV7_EVENT_ATTR(14, l1i_cache);
+static ARMV7_EVENT_ATTR(15, l1d_cache_wb);
+static ARMV7_EVENT_ATTR(16, l2d_cache);
+static ARMV7_EVENT_ATTR(17, l2d_cache_refill);
+static ARMV7_EVENT_ATTR(18, l2d_cache_wb);
+static ARMV7_EVENT_ATTR(19, bus_access);
+static ARMV7_EVENT_ATTR(1a, memory_error);
+static ARMV7_EVENT_ATTR(1b, inst_spec);
+static ARMV7_EVENT_ATTR(1c, ttbr_write_retired);
+static ARMV7_EVENT_ATTR(1d, bus_cycles);
+static ARMV7_EVENT_ATTR(40, java_bc_exec);
+static ARMV7_EVENT_ATTR(40, l1d_cache_ld);
+static ARMV7_EVENT_ATTR(40, wb_full);
+static ARMV7_EVENT_ATTR(41, java_swbc_exec);
+static ARMV7_EVENT_ATTR(41, l1d_cache_st);
+static ARMV7_EVENT_ATTR(41, l2_store_merged);
+static ARMV7_EVENT_ATTR(42, jazelle_branch_executed);
+static ARMV7_EVENT_ATTR(42, l1d_cache_refill_ld);
+static ARMV7_EVENT_ATTR(42, l2_store_bufferable);
+static ARMV7_EVENT_ATTR(43, l1d_cache_refill_st);
+static ARMV7_EVENT_ATTR(43, l2_access);
+static ARMV7_EVENT_ATTR(44, l2_miss);
+static ARMV7_EVENT_ATTR(45, axi_read);
+static ARMV7_EVENT_ATTR(46, axi_write);
+static ARMV7_EVENT_ATTR(46, l1d_cache_wb_victim);
+static ARMV7_EVENT_ATTR(47, l1d_cache_wb_clean);
+static ARMV7_EVENT_ATTR(47, mem_replay);
+static ARMV7_EVENT_ATTR(48, l1d_cache_inval);
+static ARMV7_EVENT_ATTR(48, mem_replay_unaligned);
+static ARMV7_EVENT_ATTR(49, l1d_miss_hash);
+static ARMV7_EVENT_ATTR(4a, l1i_miss_hash);
+static ARMV7_EVENT_ATTR(4b, l1d_page_coloring);
+static ARMV7_EVENT_ATTR(4c, l1d_hit_neon);
+static ARMV7_EVENT_ATTR(4c, l1d_tlb_refill_ld);
+static ARMV7_EVENT_ATTR(4d, l1d_access_neon);
+static ARMV7_EVENT_ATTR(4d, l1d_tlb_refill_st);
+static ARMV7_EVENT_ATTR(4e, l2_access_neon);
+static ARMV7_EVENT_ATTR(4f, l2_hit_neon);
+static ARMV7_EVENT_ATTR(50, coherent_miss);
+static ARMV7_EVENT_ATTR(50, l1i_access);
+static ARMV7_EVENT_ATTR(50, l2d_cache_ld);
+static ARMV7_EVENT_ATTR(51, coherent_hit);
+static ARMV7_EVENT_ATTR(51, l2d_cache_st);
+static ARMV7_EVENT_ATTR(51, return_mispredict);
+static ARMV7_EVENT_ATTR(52, branch_mispredict);
+static ARMV7_EVENT_ATTR(52, l2d_cache_refill_ld);
+static ARMV7_EVENT_ATTR(53, branch_predict_taken);
+static ARMV7_EVENT_ATTR(53, l2d_cache_refill_st);
+static ARMV7_EVENT_ATTR(54, branch_predictable_taken);
+static ARMV7_EVENT_ATTR(55, operation_issued);
+static ARMV7_EVENT_ATTR(56, inst_stall);
+static ARMV7_EVENT_ATTR(56, l2d_cache_wb_victim);
+static ARMV7_EVENT_ATTR(57, inst_issued);
+static ARMV7_EVENT_ATTR(57, l2d_cache_wb_clean);
+static ARMV7_EVENT_ATTR(58, l2d_cache_inval);
+static ARMV7_EVENT_ATTR(58, stall_neon_data);
+static ARMV7_EVENT_ATTR(59, stall_neon_inst);
+static ARMV7_EVENT_ATTR(5a, int_neon_busy);
+static ARMV7_EVENT_ATTR(60, bus_access_ld);
+static ARMV7_EVENT_ATTR(60, stall_inst);
+static ARMV7_EVENT_ATTR(61, bus_access_st);
+static ARMV7_EVENT_ATTR(61, stall_data);
+static ARMV7_EVENT_ATTR(62, bus_access_shared);
+static ARMV7_EVENT_ATTR(62, stall_tlb);
+static ARMV7_EVENT_ATTR(63, bus_access_not_shared);
+static ARMV7_EVENT_ATTR(63, strex_pass);
+static ARMV7_EVENT_ATTR(64, bus_access_normal);
+static ARMV7_EVENT_ATTR(64, strex_failed);
+static ARMV7_EVENT_ATTR(65, bus_access_periph);
+static ARMV7_EVENT_ATTR(65, data_evict);
+static ARMV7_EVENT_ATTR(66, issue_no_dispatch);
+static ARMV7_EVENT_ATTR(66, mem_access_ld);
+static ARMV7_EVENT_ATTR(67, issue_empty);
+static ARMV7_EVENT_ATTR(67, mem_access_st);
+static ARMV7_EVENT_ATTR(68, inst_exec);
+static ARMV7_EVENT_ATTR(68, unaligned_ld_spec);
+static ARMV7_EVENT_ATTR(69, cache_linefill);
+static ARMV7_EVENT_ATTR(69, unaligned_st_spec);
+static ARMV7_EVENT_ATTR(6a, prefetch_linefill);
+static ARMV7_EVENT_ATTR(6a, unaligned_ldst_spec);
+static ARMV7_EVENT_ATTR(6b, prefetch_hit);
+static ARMV7_EVENT_ATTR(6c, ldrex_spec);
+static ARMV7_EVENT_ATTR(6d, strex_pass_spec);
+static ARMV7_EVENT_ATTR(6e, predictable_ret);
+static ARMV7_EVENT_ATTR(6e, strex_fail_spec);
+static ARMV7_EVENT_ATTR(6f, strex_spec);
+static ARMV7_EVENT_ATTR(70, inst_main_exec);
+static ARMV7_EVENT_ATTR(70, ld_spec);
+static ARMV7_EVENT_ATTR(70, pmuextin0);
+static ARMV7_EVENT_ATTR(71, inst_second_exec);
+static ARMV7_EVENT_ATTR(71, pmuextin1);
+static ARMV7_EVENT_ATTR(71, st_spec);
+static ARMV7_EVENT_ATTR(72, inst_load_store);
+static ARMV7_EVENT_ATTR(72, ldst_spec);
+static ARMV7_EVENT_ATTR(72, pmuextin);
+static ARMV7_EVENT_ATTR(73, dp_spec);
+static ARMV7_EVENT_ATTR(73, inst_fp);
+static ARMV7_EVENT_ATTR(74, ase_spec);
+static ARMV7_EVENT_ATTR(74, inst_neon);
+static ARMV7_EVENT_ATTR(75, vfp_spec);
+static ARMV7_EVENT_ATTR(76, pc_write_spec);
+static ARMV7_EVENT_ATTR(78, br_immed_spec);
+static ARMV7_EVENT_ATTR(79, br_return_spec);
+static ARMV7_EVENT_ATTR(7a, br_indirect_spec);
+static ARMV7_EVENT_ATTR(7c, isb_spec);
+static ARMV7_EVENT_ATTR(7d, dsb_spec);
+static ARMV7_EVENT_ATTR(7e, dmb_spec);
+static ARMV7_EVENT_ATTR(80, stall_pld);
+static ARMV7_EVENT_ATTR(81, exc_undef);
+static ARMV7_EVENT_ATTR(81, stall_write);
+static ARMV7_EVENT_ATTR(82, stall_inst_tlb);
+static ARMV7_EVENT_ATTR(83, stall_data_tlb);
+static ARMV7_EVENT_ATTR(84, stall_inst_mtlb);
+static ARMV7_EVENT_ATTR(85, stall_data_mtlb);
+static ARMV7_EVENT_ATTR(86, exc_irq);
+static ARMV7_EVENT_ATTR(86, stall_dmb);
+static ARMV7_EVENT_ATTR(87, exc_fiq);
+static ARMV7_EVENT_ATTR(8a, clock_int);
+static ARMV7_EVENT_ATTR(8a, exc_hvc);
+static ARMV7_EVENT_ATTR(8b, clock_data);
+static ARMV7_EVENT_ATTR(8c, clock_neon);
+static ARMV7_EVENT_ATTR(8d, tlb_inst);
+static ARMV7_EVENT_ATTR(8e, tlb_data);
+static ARMV7_EVENT_ATTR(90, inst_isb);
+static ARMV7_EVENT_ATTR(91, inst_dsb);
+static ARMV7_EVENT_ATTR(92, inst_dmb);
+static ARMV7_EVENT_ATTR(93, ext_irq);
+static ARMV7_EVENT_ATTR(c0, ext_mem_req);
+static ARMV7_EVENT_ATTR(c0, stall_inst_linefill);
+static ARMV7_EVENT_ATTR(c1, ext_mem_req_nc);
+static ARMV7_EVENT_ATTR(c1, stall_inst_tlb);
+static ARMV7_EVENT_ATTR(c2, cache_tag);
+static ARMV7_EVENT_ATTR(c2, prefetch_linefill);
+static ARMV7_EVENT_ATTR(c3, cache_data);
+static ARMV7_EVENT_ATTR(c3, prefetch_linefill_drop);
+static ARMV7_EVENT_ATTR(c4, cache_btac);
+static ARMV7_EVENT_ATTR(c4, read_alloc_enter);
+static ARMV7_EVENT_ATTR(c5, read_alloc);
+static ARMV7_EVENT_ATTR(c7, etm_out0);
+static ARMV7_EVENT_ATTR(c8, etm_out1);
+static ARMV7_EVENT_ATTR(c9, stall_sb_full);
+static ARMV7_EVENT_ATTR(ca, local_cluster_snoop);
+static ARMV7_EVENT_ATTR(d3, busy_lsu);
+static ARMV7_EVENT_ATTR(d8, busy_lsi);
+static ARMV7_EVENT_ATTR(d9, busy_dpi);
+static ARMV7_EVENT_ATTR(da, busy_dei);
+static ARMV7_EVENT_ATTR(db, neon_cond_fail);
+static ARMV7_EVENT_ATTR(dc, trap_hv);
+static ARMV7_EVENT_ATTR(de, ptm_extout0);
+static ARMV7_EVENT_ATTR(df, ptm_extout1);
+static ARMV7_EVENT_ATTR(e0, mmu_walk);
+static ARMV7_EVENT_ATTR(e1, mmu_s1_walk);
+static ARMV7_EVENT_ATTR(e2, mmu_s2_walk);
+static ARMV7_EVENT_ATTR(e3, mmu_lsu_walk);
+static ARMV7_EVENT_ATTR(e4, mmu_inst_walk);
+static ARMV7_EVENT_ATTR(e5, mmu_pre_walk);
+static ARMV7_EVENT_ATTR(e6, mmu_cp15_walk);
+static ARMV7_EVENT_ATTR(e7, tlb_pld_refill);
+static ARMV7_EVENT_ATTR(e8, tlb_cp15_refill);
+static ARMV7_EVENT_ATTR(e9, tlb_flush);
+static ARMV7_EVENT_ATTR(ea, tlb_access);
+static ARMV7_EVENT_ATTR(eb, tlb_miss);
+
+static struct attribute *armv7_a8_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0e_br_return_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_40_wb_full.attr.attr,
+ &armv7_event_attr_41_l2_store_merged.attr.attr,
+ &armv7_event_attr_42_l2_store_bufferable.attr.attr,
+ &armv7_event_attr_43_l2_access.attr.attr,
+ &armv7_event_attr_44_l2_miss.attr.attr,
+ &armv7_event_attr_45_axi_read.attr.attr,
+ &armv7_event_attr_46_axi_write.attr.attr,
+ &armv7_event_attr_47_mem_replay.attr.attr,
+ &armv7_event_attr_48_mem_replay_unaligned.attr.attr,
+ &armv7_event_attr_49_l1d_miss_hash.attr.attr,
+ &armv7_event_attr_4a_l1i_miss_hash.attr.attr,
+ &armv7_event_attr_4b_l1d_page_coloring.attr.attr,
+ &armv7_event_attr_4c_l1d_hit_neon.attr.attr,
+ &armv7_event_attr_4d_l1d_access_neon.attr.attr,
+ &armv7_event_attr_4e_l2_access_neon.attr.attr,
+ &armv7_event_attr_4f_l2_hit_neon.attr.attr,
+ &armv7_event_attr_50_l1i_access.attr.attr,
+ &armv7_event_attr_51_return_mispredict.attr.attr,
+ &armv7_event_attr_52_branch_mispredict.attr.attr,
+ &armv7_event_attr_53_branch_predict_taken.attr.attr,
+ &armv7_event_attr_54_branch_predictable_taken.attr.attr,
+ &armv7_event_attr_55_operation_issued.attr.attr,
+ &armv7_event_attr_56_inst_stall.attr.attr,
+ &armv7_event_attr_57_inst_issued.attr.attr,
+ &armv7_event_attr_58_stall_neon_data.attr.attr,
+ &armv7_event_attr_59_stall_neon_inst.attr.attr,
+ &armv7_event_attr_5a_int_neon_busy.attr.attr,
+ &armv7_event_attr_70_pmuextin0.attr.attr,
+ &armv7_event_attr_71_pmuextin1.attr.attr,
+ &armv7_event_attr_72_pmuextin.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a8_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a8_event_attrs,
+};
+
+static const struct attribute_group *armv7_a8_attr_groups[] = {
+ &armv7_a8_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a9_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_40_java_bc_exec.attr.attr,
+ &armv7_event_attr_41_java_swbc_exec.attr.attr,
+ &armv7_event_attr_42_jazelle_branch_executed.attr.attr,
+ &armv7_event_attr_50_coherent_miss.attr.attr,
+ &armv7_event_attr_51_coherent_hit.attr.attr,
+ &armv7_event_attr_60_stall_inst.attr.attr,
+ &armv7_event_attr_61_stall_data.attr.attr,
+ &armv7_event_attr_62_stall_tlb.attr.attr,
+ &armv7_event_attr_63_strex_pass.attr.attr,
+ &armv7_event_attr_64_strex_failed.attr.attr,
+ &armv7_event_attr_65_data_evict.attr.attr,
+ &armv7_event_attr_66_issue_no_dispatch.attr.attr,
+ &armv7_event_attr_67_issue_empty.attr.attr,
+ &armv7_event_attr_68_inst_exec.attr.attr,
+ &armv7_event_attr_69_cache_linefill.attr.attr,
+ &armv7_event_attr_6a_prefetch_linefill.attr.attr,
+ &armv7_event_attr_6b_prefetch_hit.attr.attr,
+ &armv7_event_attr_6e_predictable_ret.attr.attr,
+ &armv7_event_attr_70_inst_main_exec.attr.attr,
+ &armv7_event_attr_71_inst_second_exec.attr.attr,
+ &armv7_event_attr_72_inst_load_store.attr.attr,
+ &armv7_event_attr_73_inst_fp.attr.attr,
+ &armv7_event_attr_74_inst_neon.attr.attr,
+ &armv7_event_attr_80_stall_pld.attr.attr,
+ &armv7_event_attr_81_stall_write.attr.attr,
+ &armv7_event_attr_82_stall_inst_tlb.attr.attr,
+ &armv7_event_attr_83_stall_data_tlb.attr.attr,
+ &armv7_event_attr_84_stall_inst_mtlb.attr.attr,
+ &armv7_event_attr_85_stall_data_mtlb.attr.attr,
+ &armv7_event_attr_86_stall_dmb.attr.attr,
+ &armv7_event_attr_8a_clock_int.attr.attr,
+ &armv7_event_attr_8b_clock_data.attr.attr,
+ &armv7_event_attr_8c_clock_neon.attr.attr,
+ &armv7_event_attr_8d_tlb_inst.attr.attr,
+ &armv7_event_attr_8e_tlb_data.attr.attr,
+ &armv7_event_attr_90_inst_isb.attr.attr,
+ &armv7_event_attr_91_inst_dsb.attr.attr,
+ &armv7_event_attr_92_inst_dmb.attr.attr,
+ &armv7_event_attr_93_ext_irq.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a9_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a9_event_attrs,
+};
+
+static const struct attribute_group *armv7_a9_attr_groups[] = {
+ &armv7_a9_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a5_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0e_br_return_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_86_exc_irq.attr.attr,
+ &armv7_event_attr_87_exc_fiq.attr.attr,
+ &armv7_event_attr_c0_ext_mem_req.attr.attr,
+ &armv7_event_attr_c1_ext_mem_req_nc.attr.attr,
+ &armv7_event_attr_c2_prefetch_linefill.attr.attr,
+ &armv7_event_attr_c3_prefetch_linefill_drop.attr.attr,
+ &armv7_event_attr_c4_read_alloc_enter.attr.attr,
+ &armv7_event_attr_c5_read_alloc.attr.attr,
+ &armv7_event_attr_c7_etm_out0.attr.attr,
+ &armv7_event_attr_c8_etm_out1.attr.attr,
+ &armv7_event_attr_c9_stall_sb_full.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a5_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a5_event_attrs,
+};
+
+static const struct attribute_group *armv7_a5_attr_groups[] = {
+ &armv7_a5_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a15_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_16_l2d_cache.attr.attr,
+ &armv7_event_attr_17_l2d_cache_refill.attr.attr,
+ &armv7_event_attr_18_l2d_cache_wb.attr.attr,
+ &armv7_event_attr_19_bus_access.attr.attr,
+ &armv7_event_attr_1a_memory_error.attr.attr,
+ &armv7_event_attr_1b_inst_spec.attr.attr,
+ &armv7_event_attr_1c_ttbr_write_retired.attr.attr,
+ &armv7_event_attr_1d_bus_cycles.attr.attr,
+ &armv7_event_attr_40_l1d_cache_ld.attr.attr,
+ &armv7_event_attr_41_l1d_cache_st.attr.attr,
+ &armv7_event_attr_42_l1d_cache_refill_ld.attr.attr,
+ &armv7_event_attr_43_l1d_cache_refill_st.attr.attr,
+ &armv7_event_attr_46_l1d_cache_wb_victim.attr.attr,
+ &armv7_event_attr_47_l1d_cache_wb_clean.attr.attr,
+ &armv7_event_attr_48_l1d_cache_inval.attr.attr,
+ &armv7_event_attr_4c_l1d_tlb_refill_ld.attr.attr,
+ &armv7_event_attr_4d_l1d_tlb_refill_st.attr.attr,
+ &armv7_event_attr_50_l2d_cache_ld.attr.attr,
+ &armv7_event_attr_51_l2d_cache_st.attr.attr,
+ &armv7_event_attr_52_l2d_cache_refill_ld.attr.attr,
+ &armv7_event_attr_53_l2d_cache_refill_st.attr.attr,
+ &armv7_event_attr_56_l2d_cache_wb_victim.attr.attr,
+ &armv7_event_attr_57_l2d_cache_wb_clean.attr.attr,
+ &armv7_event_attr_58_l2d_cache_inval.attr.attr,
+ &armv7_event_attr_60_bus_access_ld.attr.attr,
+ &armv7_event_attr_61_bus_access_st.attr.attr,
+ &armv7_event_attr_62_bus_access_shared.attr.attr,
+ &armv7_event_attr_63_bus_access_not_shared.attr.attr,
+ &armv7_event_attr_64_bus_access_normal.attr.attr,
+ &armv7_event_attr_65_bus_access_periph.attr.attr,
+ &armv7_event_attr_66_mem_access_ld.attr.attr,
+ &armv7_event_attr_67_mem_access_st.attr.attr,
+ &armv7_event_attr_68_unaligned_ld_spec.attr.attr,
+ &armv7_event_attr_69_unaligned_st_spec.attr.attr,
+ &armv7_event_attr_6a_unaligned_ldst_spec.attr.attr,
+ &armv7_event_attr_6c_ldrex_spec.attr.attr,
+ &armv7_event_attr_6d_strex_pass_spec.attr.attr,
+ &armv7_event_attr_6e_strex_fail_spec.attr.attr,
+ &armv7_event_attr_70_ld_spec.attr.attr,
+ &armv7_event_attr_71_st_spec.attr.attr,
+ &armv7_event_attr_72_ldst_spec.attr.attr,
+ &armv7_event_attr_73_dp_spec.attr.attr,
+ &armv7_event_attr_74_ase_spec.attr.attr,
+ &armv7_event_attr_75_vfp_spec.attr.attr,
+ &armv7_event_attr_76_pc_write_spec.attr.attr,
+ &armv7_event_attr_78_br_immed_spec.attr.attr,
+ &armv7_event_attr_79_br_return_spec.attr.attr,
+ &armv7_event_attr_7a_br_indirect_spec.attr.attr,
+ &armv7_event_attr_7c_isb_spec.attr.attr,
+ &armv7_event_attr_7d_dsb_spec.attr.attr,
+ &armv7_event_attr_7e_dmb_spec.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a15_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a15_event_attrs,
+};
+
+static const struct attribute_group *armv7_a15_attr_groups[] = {
+ &armv7_a15_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a7_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0e_br_return_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_16_l2d_cache.attr.attr,
+ &armv7_event_attr_17_l2d_cache_refill.attr.attr,
+ &armv7_event_attr_18_l2d_cache_wb.attr.attr,
+ &armv7_event_attr_19_bus_access.attr.attr,
+ &armv7_event_attr_1d_bus_cycles.attr.attr,
+ &armv7_event_attr_60_bus_access_ld.attr.attr,
+ &armv7_event_attr_61_bus_access_st.attr.attr,
+ &armv7_event_attr_86_exc_irq.attr.attr,
+ &armv7_event_attr_87_exc_fiq.attr.attr,
+ &armv7_event_attr_c0_ext_mem_req.attr.attr,
+ &armv7_event_attr_c1_ext_mem_req_nc.attr.attr,
+ &armv7_event_attr_c2_prefetch_linefill.attr.attr,
+ &armv7_event_attr_c3_prefetch_linefill_drop.attr.attr,
+ &armv7_event_attr_c4_read_alloc_enter.attr.attr,
+ &armv7_event_attr_c5_read_alloc.attr.attr,
+ &armv7_event_attr_c7_etm_out0.attr.attr,
+ &armv7_event_attr_c8_etm_out1.attr.attr,
+ &armv7_event_attr_c9_stall_sb_full.attr.attr,
+ &armv7_event_attr_ca_local_cluster_snoop.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a7_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a7_event_attrs,
+};
+
+static const struct attribute_group *armv7_a7_attr_groups[] = {
+ &armv7_a7_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a17_event_attrs[] = {
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_16_l2d_cache.attr.attr,
+ &armv7_event_attr_17_l2d_cache_refill.attr.attr,
+ &armv7_event_attr_18_l2d_cache_wb.attr.attr,
+ &armv7_event_attr_19_bus_access.attr.attr,
+ &armv7_event_attr_1b_inst_spec.attr.attr,
+ &armv7_event_attr_1c_ttbr_write_retired.attr.attr,
+ &armv7_event_attr_1d_bus_cycles.attr.attr,
+ &armv7_event_attr_40_l1d_cache_ld.attr.attr,
+ &armv7_event_attr_41_l1d_cache_st.attr.attr,
+ &armv7_event_attr_50_l2d_cache_ld.attr.attr,
+ &armv7_event_attr_51_l2d_cache_st.attr.attr,
+ &armv7_event_attr_56_l2d_cache_wb_victim.attr.attr,
+ &armv7_event_attr_57_l2d_cache_wb_clean.attr.attr,
+ &armv7_event_attr_58_l2d_cache_inval.attr.attr,
+ &armv7_event_attr_62_bus_access_shared.attr.attr,
+ &armv7_event_attr_63_bus_access_not_shared.attr.attr,
+ &armv7_event_attr_64_bus_access_normal.attr.attr,
+ &armv7_event_attr_65_bus_access_periph.attr.attr,
+ &armv7_event_attr_66_mem_access_ld.attr.attr,
+ &armv7_event_attr_67_mem_access_st.attr.attr,
+ &armv7_event_attr_68_unaligned_ld_spec.attr.attr,
+ &armv7_event_attr_69_unaligned_st_spec.attr.attr,
+ &armv7_event_attr_6a_unaligned_ldst_spec.attr.attr,
+ &armv7_event_attr_6c_ldrex_spec.attr.attr,
+ &armv7_event_attr_6e_strex_fail_spec.attr.attr,
+ &armv7_event_attr_6f_strex_spec.attr.attr,
+ &armv7_event_attr_70_ld_spec.attr.attr,
+ &armv7_event_attr_71_st_spec.attr.attr,
+ &armv7_event_attr_72_ldst_spec.attr.attr,
+ &armv7_event_attr_73_dp_spec.attr.attr,
+ &armv7_event_attr_74_ase_spec.attr.attr,
+ &armv7_event_attr_75_vfp_spec.attr.attr,
+ &armv7_event_attr_76_pc_write_spec.attr.attr,
+ &armv7_event_attr_78_br_immed_spec.attr.attr,
+ &armv7_event_attr_79_br_return_spec.attr.attr,
+ &armv7_event_attr_7a_br_indirect_spec.attr.attr,
+ &armv7_event_attr_7c_isb_spec.attr.attr,
+ &armv7_event_attr_7d_dsb_spec.attr.attr,
+ &armv7_event_attr_7e_dmb_spec.attr.attr,
+ &armv7_event_attr_81_exc_undef.attr.attr,
+ &armv7_event_attr_8a_exc_hvc.attr.attr,
+ &armv7_event_attr_c0_stall_inst_linefill.attr.attr,
+ &armv7_event_attr_c1_stall_inst_tlb.attr.attr,
+ &armv7_event_attr_c2_cache_tag.attr.attr,
+ &armv7_event_attr_c3_cache_data.attr.attr,
+ &armv7_event_attr_c4_cache_btac.attr.attr,
+ &armv7_event_attr_ca_local_cluster_snoop.attr.attr,
+ &armv7_event_attr_d3_busy_lsu.attr.attr,
+ &armv7_event_attr_d8_busy_lsi.attr.attr,
+ &armv7_event_attr_d9_busy_dpi.attr.attr,
+ &armv7_event_attr_da_busy_dei.attr.attr,
+ &armv7_event_attr_db_neon_cond_fail.attr.attr,
+ &armv7_event_attr_dc_trap_hv.attr.attr,
+ &armv7_event_attr_de_ptm_extout0.attr.attr,
+ &armv7_event_attr_df_ptm_extout1.attr.attr,
+ &armv7_event_attr_e0_mmu_walk.attr.attr,
+ &armv7_event_attr_e1_mmu_s1_walk.attr.attr,
+ &armv7_event_attr_e2_mmu_s2_walk.attr.attr,
+ &armv7_event_attr_e3_mmu_lsu_walk.attr.attr,
+ &armv7_event_attr_e4_mmu_inst_walk.attr.attr,
+ &armv7_event_attr_e5_mmu_pre_walk.attr.attr,
+ &armv7_event_attr_e6_mmu_cp15_walk.attr.attr,
+ &armv7_event_attr_e7_tlb_pld_refill.attr.attr,
+ &armv7_event_attr_e8_tlb_cp15_refill.attr.attr,
+ &armv7_event_attr_e9_tlb_flush.attr.attr,
+ &armv7_event_attr_ea_tlb_access.attr.attr,
+ &armv7_event_attr_eb_tlb_miss.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a17_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a17_event_attrs,
+};
+
+static const struct attribute_group *armv7_a17_attr_groups[] = {
+ &armv7_a17_events_attr_group,
+ NULL
+};
+
/*
* Perf Events' indices
*/
@@ -1085,6 +1695,7 @@ static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
armv7pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a8";
cpu_pmu->map_event = armv7_a8_map_event;
+ cpu_pmu->pmu.attr_groups = armv7_a8_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1093,6 +1704,7 @@ static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
armv7pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a9";
cpu_pmu->map_event = armv7_a9_map_event;
+ cpu_pmu->pmu.attr_groups = armv7_a9_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1101,6 +1713,7 @@ static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
armv7pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a5";
cpu_pmu->map_event = armv7_a5_map_event;
+ cpu_pmu->pmu.attr_groups = armv7_a5_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1110,6 +1723,7 @@ static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->name = "armv7_cortex_a15";
cpu_pmu->map_event = armv7_a15_map_event;
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->pmu.attr_groups = armv7_a15_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1119,6 +1733,7 @@ static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->name = "armv7_cortex_a7";
cpu_pmu->map_event = armv7_a7_map_event;
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->pmu.attr_groups = armv7_a7_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1128,6 +1743,7 @@ static int armv7_a12_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->name = "armv7_cortex_a12";
cpu_pmu->map_event = armv7_a12_map_event;
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->pmu.attr_groups = armv7_a17_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1135,6 +1751,7 @@ static int armv7_a17_pmu_init(struct arm_pmu *cpu_pmu)
{
int ret = armv7_a12_pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a17";
+ cpu_pmu->pmu.attr_groups = armv7_a17_attr_groups;
return ret;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-08-04 0:15 ` Drew Richardson
0 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-08-04 0:15 UTC (permalink / raw)
To: linux-arm-kernel
Add additional information about hardware events to make counters self
describing. This makes the hardware PMUs easier to use as perf list
contains the possible events instead of users having to refer to
documentation like the ARM TRMs. This could also allow tools like
oprofile to support PMUs without requiring an update.
Signed-off-by: Drew Richardson <drew.richardson@arm.com>
---
arch/arm/kernel/perf_event.c | 1 +
arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 618 insertions(+)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 54272e0be713..a7f2c84bae15 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -548,6 +548,7 @@ static void armpmu_init(struct arm_pmu *armpmu)
.stop = armpmu_stop,
.read = armpmu_read,
.filter_match = armpmu_filter_match,
+ .attr_groups = armpmu->pmu.attr_groups,
};
}
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index f9b37f876e20..d46bc78b5997 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -547,6 +547,616 @@ static const unsigned scorpion_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
[C(BPU)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
};
+static ssize_t armv7_event_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dev_ext_attribute *ea = container_of(attr,
+ struct dev_ext_attribute,
+ attr);
+
+ return snprintf(buf, PAGE_SIZE, "%s\n", (char *)ea->var);
+}
+
+#define ARMV7_EVENT_ATTR(config, name) \
+ struct dev_ext_attribute armv7_event_attr_##config##_##name = \
+ { __ATTR(name, S_IRUGO, armv7_event_show, NULL), \
+ "config=0x" #config }
+
+static ARMV7_EVENT_ATTR(00, sw_incr);
+static ARMV7_EVENT_ATTR(01, l1i_cache_refill);
+static ARMV7_EVENT_ATTR(02, l1i_tlb_refill);
+static ARMV7_EVENT_ATTR(03, l1d_cache_refill);
+static ARMV7_EVENT_ATTR(04, l1d_cache);
+static ARMV7_EVENT_ATTR(05, l1d_tlb_refill);
+static ARMV7_EVENT_ATTR(06, ld_retired);
+static ARMV7_EVENT_ATTR(07, st_retired);
+static ARMV7_EVENT_ATTR(08, inst_retired);
+static ARMV7_EVENT_ATTR(09, exc_taken);
+static ARMV7_EVENT_ATTR(0a, exc_return);
+static ARMV7_EVENT_ATTR(0b, cid_write_retired);
+static ARMV7_EVENT_ATTR(0c, pc_write_retired);
+static ARMV7_EVENT_ATTR(0d, br_immed_retired);
+static ARMV7_EVENT_ATTR(0e, br_return_retired);
+static ARMV7_EVENT_ATTR(0f, unaligned_ldst_retired);
+static ARMV7_EVENT_ATTR(10, br_mis_pred);
+static ARMV7_EVENT_ATTR(11, cpu_cycles);
+static ARMV7_EVENT_ATTR(12, br_pred);
+static ARMV7_EVENT_ATTR(13, mem_access);
+static ARMV7_EVENT_ATTR(14, l1i_cache);
+static ARMV7_EVENT_ATTR(15, l1d_cache_wb);
+static ARMV7_EVENT_ATTR(16, l2d_cache);
+static ARMV7_EVENT_ATTR(17, l2d_cache_refill);
+static ARMV7_EVENT_ATTR(18, l2d_cache_wb);
+static ARMV7_EVENT_ATTR(19, bus_access);
+static ARMV7_EVENT_ATTR(1a, memory_error);
+static ARMV7_EVENT_ATTR(1b, inst_spec);
+static ARMV7_EVENT_ATTR(1c, ttbr_write_retired);
+static ARMV7_EVENT_ATTR(1d, bus_cycles);
+static ARMV7_EVENT_ATTR(40, java_bc_exec);
+static ARMV7_EVENT_ATTR(40, l1d_cache_ld);
+static ARMV7_EVENT_ATTR(40, wb_full);
+static ARMV7_EVENT_ATTR(41, java_swbc_exec);
+static ARMV7_EVENT_ATTR(41, l1d_cache_st);
+static ARMV7_EVENT_ATTR(41, l2_store_merged);
+static ARMV7_EVENT_ATTR(42, jazelle_branch_executed);
+static ARMV7_EVENT_ATTR(42, l1d_cache_refill_ld);
+static ARMV7_EVENT_ATTR(42, l2_store_bufferable);
+static ARMV7_EVENT_ATTR(43, l1d_cache_refill_st);
+static ARMV7_EVENT_ATTR(43, l2_access);
+static ARMV7_EVENT_ATTR(44, l2_miss);
+static ARMV7_EVENT_ATTR(45, axi_read);
+static ARMV7_EVENT_ATTR(46, axi_write);
+static ARMV7_EVENT_ATTR(46, l1d_cache_wb_victim);
+static ARMV7_EVENT_ATTR(47, l1d_cache_wb_clean);
+static ARMV7_EVENT_ATTR(47, mem_replay);
+static ARMV7_EVENT_ATTR(48, l1d_cache_inval);
+static ARMV7_EVENT_ATTR(48, mem_replay_unaligned);
+static ARMV7_EVENT_ATTR(49, l1d_miss_hash);
+static ARMV7_EVENT_ATTR(4a, l1i_miss_hash);
+static ARMV7_EVENT_ATTR(4b, l1d_page_coloring);
+static ARMV7_EVENT_ATTR(4c, l1d_hit_neon);
+static ARMV7_EVENT_ATTR(4c, l1d_tlb_refill_ld);
+static ARMV7_EVENT_ATTR(4d, l1d_access_neon);
+static ARMV7_EVENT_ATTR(4d, l1d_tlb_refill_st);
+static ARMV7_EVENT_ATTR(4e, l2_access_neon);
+static ARMV7_EVENT_ATTR(4f, l2_hit_neon);
+static ARMV7_EVENT_ATTR(50, coherent_miss);
+static ARMV7_EVENT_ATTR(50, l1i_access);
+static ARMV7_EVENT_ATTR(50, l2d_cache_ld);
+static ARMV7_EVENT_ATTR(51, coherent_hit);
+static ARMV7_EVENT_ATTR(51, l2d_cache_st);
+static ARMV7_EVENT_ATTR(51, return_mispredict);
+static ARMV7_EVENT_ATTR(52, branch_mispredict);
+static ARMV7_EVENT_ATTR(52, l2d_cache_refill_ld);
+static ARMV7_EVENT_ATTR(53, branch_predict_taken);
+static ARMV7_EVENT_ATTR(53, l2d_cache_refill_st);
+static ARMV7_EVENT_ATTR(54, branch_predictable_taken);
+static ARMV7_EVENT_ATTR(55, operation_issued);
+static ARMV7_EVENT_ATTR(56, inst_stall);
+static ARMV7_EVENT_ATTR(56, l2d_cache_wb_victim);
+static ARMV7_EVENT_ATTR(57, inst_issued);
+static ARMV7_EVENT_ATTR(57, l2d_cache_wb_clean);
+static ARMV7_EVENT_ATTR(58, l2d_cache_inval);
+static ARMV7_EVENT_ATTR(58, stall_neon_data);
+static ARMV7_EVENT_ATTR(59, stall_neon_inst);
+static ARMV7_EVENT_ATTR(5a, int_neon_busy);
+static ARMV7_EVENT_ATTR(60, bus_access_ld);
+static ARMV7_EVENT_ATTR(60, stall_inst);
+static ARMV7_EVENT_ATTR(61, bus_access_st);
+static ARMV7_EVENT_ATTR(61, stall_data);
+static ARMV7_EVENT_ATTR(62, bus_access_shared);
+static ARMV7_EVENT_ATTR(62, stall_tlb);
+static ARMV7_EVENT_ATTR(63, bus_access_not_shared);
+static ARMV7_EVENT_ATTR(63, strex_pass);
+static ARMV7_EVENT_ATTR(64, bus_access_normal);
+static ARMV7_EVENT_ATTR(64, strex_failed);
+static ARMV7_EVENT_ATTR(65, bus_access_periph);
+static ARMV7_EVENT_ATTR(65, data_evict);
+static ARMV7_EVENT_ATTR(66, issue_no_dispatch);
+static ARMV7_EVENT_ATTR(66, mem_access_ld);
+static ARMV7_EVENT_ATTR(67, issue_empty);
+static ARMV7_EVENT_ATTR(67, mem_access_st);
+static ARMV7_EVENT_ATTR(68, inst_exec);
+static ARMV7_EVENT_ATTR(68, unaligned_ld_spec);
+static ARMV7_EVENT_ATTR(69, cache_linefill);
+static ARMV7_EVENT_ATTR(69, unaligned_st_spec);
+static ARMV7_EVENT_ATTR(6a, prefetch_linefill);
+static ARMV7_EVENT_ATTR(6a, unaligned_ldst_spec);
+static ARMV7_EVENT_ATTR(6b, prefetch_hit);
+static ARMV7_EVENT_ATTR(6c, ldrex_spec);
+static ARMV7_EVENT_ATTR(6d, strex_pass_spec);
+static ARMV7_EVENT_ATTR(6e, predictable_ret);
+static ARMV7_EVENT_ATTR(6e, strex_fail_spec);
+static ARMV7_EVENT_ATTR(6f, strex_spec);
+static ARMV7_EVENT_ATTR(70, inst_main_exec);
+static ARMV7_EVENT_ATTR(70, ld_spec);
+static ARMV7_EVENT_ATTR(70, pmuextin0);
+static ARMV7_EVENT_ATTR(71, inst_second_exec);
+static ARMV7_EVENT_ATTR(71, pmuextin1);
+static ARMV7_EVENT_ATTR(71, st_spec);
+static ARMV7_EVENT_ATTR(72, inst_load_store);
+static ARMV7_EVENT_ATTR(72, ldst_spec);
+static ARMV7_EVENT_ATTR(72, pmuextin);
+static ARMV7_EVENT_ATTR(73, dp_spec);
+static ARMV7_EVENT_ATTR(73, inst_fp);
+static ARMV7_EVENT_ATTR(74, ase_spec);
+static ARMV7_EVENT_ATTR(74, inst_neon);
+static ARMV7_EVENT_ATTR(75, vfp_spec);
+static ARMV7_EVENT_ATTR(76, pc_write_spec);
+static ARMV7_EVENT_ATTR(78, br_immed_spec);
+static ARMV7_EVENT_ATTR(79, br_return_spec);
+static ARMV7_EVENT_ATTR(7a, br_indirect_spec);
+static ARMV7_EVENT_ATTR(7c, isb_spec);
+static ARMV7_EVENT_ATTR(7d, dsb_spec);
+static ARMV7_EVENT_ATTR(7e, dmb_spec);
+static ARMV7_EVENT_ATTR(80, stall_pld);
+static ARMV7_EVENT_ATTR(81, exc_undef);
+static ARMV7_EVENT_ATTR(81, stall_write);
+static ARMV7_EVENT_ATTR(82, stall_inst_tlb);
+static ARMV7_EVENT_ATTR(83, stall_data_tlb);
+static ARMV7_EVENT_ATTR(84, stall_inst_mtlb);
+static ARMV7_EVENT_ATTR(85, stall_data_mtlb);
+static ARMV7_EVENT_ATTR(86, exc_irq);
+static ARMV7_EVENT_ATTR(86, stall_dmb);
+static ARMV7_EVENT_ATTR(87, exc_fiq);
+static ARMV7_EVENT_ATTR(8a, clock_int);
+static ARMV7_EVENT_ATTR(8a, exc_hvc);
+static ARMV7_EVENT_ATTR(8b, clock_data);
+static ARMV7_EVENT_ATTR(8c, clock_neon);
+static ARMV7_EVENT_ATTR(8d, tlb_inst);
+static ARMV7_EVENT_ATTR(8e, tlb_data);
+static ARMV7_EVENT_ATTR(90, inst_isb);
+static ARMV7_EVENT_ATTR(91, inst_dsb);
+static ARMV7_EVENT_ATTR(92, inst_dmb);
+static ARMV7_EVENT_ATTR(93, ext_irq);
+static ARMV7_EVENT_ATTR(c0, ext_mem_req);
+static ARMV7_EVENT_ATTR(c0, stall_inst_linefill);
+static ARMV7_EVENT_ATTR(c1, ext_mem_req_nc);
+static ARMV7_EVENT_ATTR(c1, stall_inst_tlb);
+static ARMV7_EVENT_ATTR(c2, cache_tag);
+static ARMV7_EVENT_ATTR(c2, prefetch_linefill);
+static ARMV7_EVENT_ATTR(c3, cache_data);
+static ARMV7_EVENT_ATTR(c3, prefetch_linefill_drop);
+static ARMV7_EVENT_ATTR(c4, cache_btac);
+static ARMV7_EVENT_ATTR(c4, read_alloc_enter);
+static ARMV7_EVENT_ATTR(c5, read_alloc);
+static ARMV7_EVENT_ATTR(c7, etm_out0);
+static ARMV7_EVENT_ATTR(c8, etm_out1);
+static ARMV7_EVENT_ATTR(c9, stall_sb_full);
+static ARMV7_EVENT_ATTR(ca, local_cluster_snoop);
+static ARMV7_EVENT_ATTR(d3, busy_lsu);
+static ARMV7_EVENT_ATTR(d8, busy_lsi);
+static ARMV7_EVENT_ATTR(d9, busy_dpi);
+static ARMV7_EVENT_ATTR(da, busy_dei);
+static ARMV7_EVENT_ATTR(db, neon_cond_fail);
+static ARMV7_EVENT_ATTR(dc, trap_hv);
+static ARMV7_EVENT_ATTR(de, ptm_extout0);
+static ARMV7_EVENT_ATTR(df, ptm_extout1);
+static ARMV7_EVENT_ATTR(e0, mmu_walk);
+static ARMV7_EVENT_ATTR(e1, mmu_s1_walk);
+static ARMV7_EVENT_ATTR(e2, mmu_s2_walk);
+static ARMV7_EVENT_ATTR(e3, mmu_lsu_walk);
+static ARMV7_EVENT_ATTR(e4, mmu_inst_walk);
+static ARMV7_EVENT_ATTR(e5, mmu_pre_walk);
+static ARMV7_EVENT_ATTR(e6, mmu_cp15_walk);
+static ARMV7_EVENT_ATTR(e7, tlb_pld_refill);
+static ARMV7_EVENT_ATTR(e8, tlb_cp15_refill);
+static ARMV7_EVENT_ATTR(e9, tlb_flush);
+static ARMV7_EVENT_ATTR(ea, tlb_access);
+static ARMV7_EVENT_ATTR(eb, tlb_miss);
+
+static struct attribute *armv7_a8_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0e_br_return_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_40_wb_full.attr.attr,
+ &armv7_event_attr_41_l2_store_merged.attr.attr,
+ &armv7_event_attr_42_l2_store_bufferable.attr.attr,
+ &armv7_event_attr_43_l2_access.attr.attr,
+ &armv7_event_attr_44_l2_miss.attr.attr,
+ &armv7_event_attr_45_axi_read.attr.attr,
+ &armv7_event_attr_46_axi_write.attr.attr,
+ &armv7_event_attr_47_mem_replay.attr.attr,
+ &armv7_event_attr_48_mem_replay_unaligned.attr.attr,
+ &armv7_event_attr_49_l1d_miss_hash.attr.attr,
+ &armv7_event_attr_4a_l1i_miss_hash.attr.attr,
+ &armv7_event_attr_4b_l1d_page_coloring.attr.attr,
+ &armv7_event_attr_4c_l1d_hit_neon.attr.attr,
+ &armv7_event_attr_4d_l1d_access_neon.attr.attr,
+ &armv7_event_attr_4e_l2_access_neon.attr.attr,
+ &armv7_event_attr_4f_l2_hit_neon.attr.attr,
+ &armv7_event_attr_50_l1i_access.attr.attr,
+ &armv7_event_attr_51_return_mispredict.attr.attr,
+ &armv7_event_attr_52_branch_mispredict.attr.attr,
+ &armv7_event_attr_53_branch_predict_taken.attr.attr,
+ &armv7_event_attr_54_branch_predictable_taken.attr.attr,
+ &armv7_event_attr_55_operation_issued.attr.attr,
+ &armv7_event_attr_56_inst_stall.attr.attr,
+ &armv7_event_attr_57_inst_issued.attr.attr,
+ &armv7_event_attr_58_stall_neon_data.attr.attr,
+ &armv7_event_attr_59_stall_neon_inst.attr.attr,
+ &armv7_event_attr_5a_int_neon_busy.attr.attr,
+ &armv7_event_attr_70_pmuextin0.attr.attr,
+ &armv7_event_attr_71_pmuextin1.attr.attr,
+ &armv7_event_attr_72_pmuextin.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a8_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a8_event_attrs,
+};
+
+static const struct attribute_group *armv7_a8_attr_groups[] = {
+ &armv7_a8_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a9_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_40_java_bc_exec.attr.attr,
+ &armv7_event_attr_41_java_swbc_exec.attr.attr,
+ &armv7_event_attr_42_jazelle_branch_executed.attr.attr,
+ &armv7_event_attr_50_coherent_miss.attr.attr,
+ &armv7_event_attr_51_coherent_hit.attr.attr,
+ &armv7_event_attr_60_stall_inst.attr.attr,
+ &armv7_event_attr_61_stall_data.attr.attr,
+ &armv7_event_attr_62_stall_tlb.attr.attr,
+ &armv7_event_attr_63_strex_pass.attr.attr,
+ &armv7_event_attr_64_strex_failed.attr.attr,
+ &armv7_event_attr_65_data_evict.attr.attr,
+ &armv7_event_attr_66_issue_no_dispatch.attr.attr,
+ &armv7_event_attr_67_issue_empty.attr.attr,
+ &armv7_event_attr_68_inst_exec.attr.attr,
+ &armv7_event_attr_69_cache_linefill.attr.attr,
+ &armv7_event_attr_6a_prefetch_linefill.attr.attr,
+ &armv7_event_attr_6b_prefetch_hit.attr.attr,
+ &armv7_event_attr_6e_predictable_ret.attr.attr,
+ &armv7_event_attr_70_inst_main_exec.attr.attr,
+ &armv7_event_attr_71_inst_second_exec.attr.attr,
+ &armv7_event_attr_72_inst_load_store.attr.attr,
+ &armv7_event_attr_73_inst_fp.attr.attr,
+ &armv7_event_attr_74_inst_neon.attr.attr,
+ &armv7_event_attr_80_stall_pld.attr.attr,
+ &armv7_event_attr_81_stall_write.attr.attr,
+ &armv7_event_attr_82_stall_inst_tlb.attr.attr,
+ &armv7_event_attr_83_stall_data_tlb.attr.attr,
+ &armv7_event_attr_84_stall_inst_mtlb.attr.attr,
+ &armv7_event_attr_85_stall_data_mtlb.attr.attr,
+ &armv7_event_attr_86_stall_dmb.attr.attr,
+ &armv7_event_attr_8a_clock_int.attr.attr,
+ &armv7_event_attr_8b_clock_data.attr.attr,
+ &armv7_event_attr_8c_clock_neon.attr.attr,
+ &armv7_event_attr_8d_tlb_inst.attr.attr,
+ &armv7_event_attr_8e_tlb_data.attr.attr,
+ &armv7_event_attr_90_inst_isb.attr.attr,
+ &armv7_event_attr_91_inst_dsb.attr.attr,
+ &armv7_event_attr_92_inst_dmb.attr.attr,
+ &armv7_event_attr_93_ext_irq.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a9_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a9_event_attrs,
+};
+
+static const struct attribute_group *armv7_a9_attr_groups[] = {
+ &armv7_a9_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a5_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0e_br_return_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_86_exc_irq.attr.attr,
+ &armv7_event_attr_87_exc_fiq.attr.attr,
+ &armv7_event_attr_c0_ext_mem_req.attr.attr,
+ &armv7_event_attr_c1_ext_mem_req_nc.attr.attr,
+ &armv7_event_attr_c2_prefetch_linefill.attr.attr,
+ &armv7_event_attr_c3_prefetch_linefill_drop.attr.attr,
+ &armv7_event_attr_c4_read_alloc_enter.attr.attr,
+ &armv7_event_attr_c5_read_alloc.attr.attr,
+ &armv7_event_attr_c7_etm_out0.attr.attr,
+ &armv7_event_attr_c8_etm_out1.attr.attr,
+ &armv7_event_attr_c9_stall_sb_full.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a5_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a5_event_attrs,
+};
+
+static const struct attribute_group *armv7_a5_attr_groups[] = {
+ &armv7_a5_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a15_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_16_l2d_cache.attr.attr,
+ &armv7_event_attr_17_l2d_cache_refill.attr.attr,
+ &armv7_event_attr_18_l2d_cache_wb.attr.attr,
+ &armv7_event_attr_19_bus_access.attr.attr,
+ &armv7_event_attr_1a_memory_error.attr.attr,
+ &armv7_event_attr_1b_inst_spec.attr.attr,
+ &armv7_event_attr_1c_ttbr_write_retired.attr.attr,
+ &armv7_event_attr_1d_bus_cycles.attr.attr,
+ &armv7_event_attr_40_l1d_cache_ld.attr.attr,
+ &armv7_event_attr_41_l1d_cache_st.attr.attr,
+ &armv7_event_attr_42_l1d_cache_refill_ld.attr.attr,
+ &armv7_event_attr_43_l1d_cache_refill_st.attr.attr,
+ &armv7_event_attr_46_l1d_cache_wb_victim.attr.attr,
+ &armv7_event_attr_47_l1d_cache_wb_clean.attr.attr,
+ &armv7_event_attr_48_l1d_cache_inval.attr.attr,
+ &armv7_event_attr_4c_l1d_tlb_refill_ld.attr.attr,
+ &armv7_event_attr_4d_l1d_tlb_refill_st.attr.attr,
+ &armv7_event_attr_50_l2d_cache_ld.attr.attr,
+ &armv7_event_attr_51_l2d_cache_st.attr.attr,
+ &armv7_event_attr_52_l2d_cache_refill_ld.attr.attr,
+ &armv7_event_attr_53_l2d_cache_refill_st.attr.attr,
+ &armv7_event_attr_56_l2d_cache_wb_victim.attr.attr,
+ &armv7_event_attr_57_l2d_cache_wb_clean.attr.attr,
+ &armv7_event_attr_58_l2d_cache_inval.attr.attr,
+ &armv7_event_attr_60_bus_access_ld.attr.attr,
+ &armv7_event_attr_61_bus_access_st.attr.attr,
+ &armv7_event_attr_62_bus_access_shared.attr.attr,
+ &armv7_event_attr_63_bus_access_not_shared.attr.attr,
+ &armv7_event_attr_64_bus_access_normal.attr.attr,
+ &armv7_event_attr_65_bus_access_periph.attr.attr,
+ &armv7_event_attr_66_mem_access_ld.attr.attr,
+ &armv7_event_attr_67_mem_access_st.attr.attr,
+ &armv7_event_attr_68_unaligned_ld_spec.attr.attr,
+ &armv7_event_attr_69_unaligned_st_spec.attr.attr,
+ &armv7_event_attr_6a_unaligned_ldst_spec.attr.attr,
+ &armv7_event_attr_6c_ldrex_spec.attr.attr,
+ &armv7_event_attr_6d_strex_pass_spec.attr.attr,
+ &armv7_event_attr_6e_strex_fail_spec.attr.attr,
+ &armv7_event_attr_70_ld_spec.attr.attr,
+ &armv7_event_attr_71_st_spec.attr.attr,
+ &armv7_event_attr_72_ldst_spec.attr.attr,
+ &armv7_event_attr_73_dp_spec.attr.attr,
+ &armv7_event_attr_74_ase_spec.attr.attr,
+ &armv7_event_attr_75_vfp_spec.attr.attr,
+ &armv7_event_attr_76_pc_write_spec.attr.attr,
+ &armv7_event_attr_78_br_immed_spec.attr.attr,
+ &armv7_event_attr_79_br_return_spec.attr.attr,
+ &armv7_event_attr_7a_br_indirect_spec.attr.attr,
+ &armv7_event_attr_7c_isb_spec.attr.attr,
+ &armv7_event_attr_7d_dsb_spec.attr.attr,
+ &armv7_event_attr_7e_dmb_spec.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a15_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a15_event_attrs,
+};
+
+static const struct attribute_group *armv7_a15_attr_groups[] = {
+ &armv7_a15_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a7_event_attrs[] = {
+ &armv7_event_attr_00_sw_incr.attr.attr,
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_06_ld_retired.attr.attr,
+ &armv7_event_attr_07_st_retired.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_0c_pc_write_retired.attr.attr,
+ &armv7_event_attr_0d_br_immed_retired.attr.attr,
+ &armv7_event_attr_0e_br_return_retired.attr.attr,
+ &armv7_event_attr_0f_unaligned_ldst_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_16_l2d_cache.attr.attr,
+ &armv7_event_attr_17_l2d_cache_refill.attr.attr,
+ &armv7_event_attr_18_l2d_cache_wb.attr.attr,
+ &armv7_event_attr_19_bus_access.attr.attr,
+ &armv7_event_attr_1d_bus_cycles.attr.attr,
+ &armv7_event_attr_60_bus_access_ld.attr.attr,
+ &armv7_event_attr_61_bus_access_st.attr.attr,
+ &armv7_event_attr_86_exc_irq.attr.attr,
+ &armv7_event_attr_87_exc_fiq.attr.attr,
+ &armv7_event_attr_c0_ext_mem_req.attr.attr,
+ &armv7_event_attr_c1_ext_mem_req_nc.attr.attr,
+ &armv7_event_attr_c2_prefetch_linefill.attr.attr,
+ &armv7_event_attr_c3_prefetch_linefill_drop.attr.attr,
+ &armv7_event_attr_c4_read_alloc_enter.attr.attr,
+ &armv7_event_attr_c5_read_alloc.attr.attr,
+ &armv7_event_attr_c7_etm_out0.attr.attr,
+ &armv7_event_attr_c8_etm_out1.attr.attr,
+ &armv7_event_attr_c9_stall_sb_full.attr.attr,
+ &armv7_event_attr_ca_local_cluster_snoop.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a7_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a7_event_attrs,
+};
+
+static const struct attribute_group *armv7_a7_attr_groups[] = {
+ &armv7_a7_events_attr_group,
+ NULL
+};
+
+static struct attribute *armv7_a17_event_attrs[] = {
+ &armv7_event_attr_01_l1i_cache_refill.attr.attr,
+ &armv7_event_attr_02_l1i_tlb_refill.attr.attr,
+ &armv7_event_attr_03_l1d_cache_refill.attr.attr,
+ &armv7_event_attr_04_l1d_cache.attr.attr,
+ &armv7_event_attr_05_l1d_tlb_refill.attr.attr,
+ &armv7_event_attr_08_inst_retired.attr.attr,
+ &armv7_event_attr_09_exc_taken.attr.attr,
+ &armv7_event_attr_0a_exc_return.attr.attr,
+ &armv7_event_attr_0b_cid_write_retired.attr.attr,
+ &armv7_event_attr_10_br_mis_pred.attr.attr,
+ &armv7_event_attr_11_cpu_cycles.attr.attr,
+ &armv7_event_attr_12_br_pred.attr.attr,
+ &armv7_event_attr_13_mem_access.attr.attr,
+ &armv7_event_attr_14_l1i_cache.attr.attr,
+ &armv7_event_attr_15_l1d_cache_wb.attr.attr,
+ &armv7_event_attr_16_l2d_cache.attr.attr,
+ &armv7_event_attr_17_l2d_cache_refill.attr.attr,
+ &armv7_event_attr_18_l2d_cache_wb.attr.attr,
+ &armv7_event_attr_19_bus_access.attr.attr,
+ &armv7_event_attr_1b_inst_spec.attr.attr,
+ &armv7_event_attr_1c_ttbr_write_retired.attr.attr,
+ &armv7_event_attr_1d_bus_cycles.attr.attr,
+ &armv7_event_attr_40_l1d_cache_ld.attr.attr,
+ &armv7_event_attr_41_l1d_cache_st.attr.attr,
+ &armv7_event_attr_50_l2d_cache_ld.attr.attr,
+ &armv7_event_attr_51_l2d_cache_st.attr.attr,
+ &armv7_event_attr_56_l2d_cache_wb_victim.attr.attr,
+ &armv7_event_attr_57_l2d_cache_wb_clean.attr.attr,
+ &armv7_event_attr_58_l2d_cache_inval.attr.attr,
+ &armv7_event_attr_62_bus_access_shared.attr.attr,
+ &armv7_event_attr_63_bus_access_not_shared.attr.attr,
+ &armv7_event_attr_64_bus_access_normal.attr.attr,
+ &armv7_event_attr_65_bus_access_periph.attr.attr,
+ &armv7_event_attr_66_mem_access_ld.attr.attr,
+ &armv7_event_attr_67_mem_access_st.attr.attr,
+ &armv7_event_attr_68_unaligned_ld_spec.attr.attr,
+ &armv7_event_attr_69_unaligned_st_spec.attr.attr,
+ &armv7_event_attr_6a_unaligned_ldst_spec.attr.attr,
+ &armv7_event_attr_6c_ldrex_spec.attr.attr,
+ &armv7_event_attr_6e_strex_fail_spec.attr.attr,
+ &armv7_event_attr_6f_strex_spec.attr.attr,
+ &armv7_event_attr_70_ld_spec.attr.attr,
+ &armv7_event_attr_71_st_spec.attr.attr,
+ &armv7_event_attr_72_ldst_spec.attr.attr,
+ &armv7_event_attr_73_dp_spec.attr.attr,
+ &armv7_event_attr_74_ase_spec.attr.attr,
+ &armv7_event_attr_75_vfp_spec.attr.attr,
+ &armv7_event_attr_76_pc_write_spec.attr.attr,
+ &armv7_event_attr_78_br_immed_spec.attr.attr,
+ &armv7_event_attr_79_br_return_spec.attr.attr,
+ &armv7_event_attr_7a_br_indirect_spec.attr.attr,
+ &armv7_event_attr_7c_isb_spec.attr.attr,
+ &armv7_event_attr_7d_dsb_spec.attr.attr,
+ &armv7_event_attr_7e_dmb_spec.attr.attr,
+ &armv7_event_attr_81_exc_undef.attr.attr,
+ &armv7_event_attr_8a_exc_hvc.attr.attr,
+ &armv7_event_attr_c0_stall_inst_linefill.attr.attr,
+ &armv7_event_attr_c1_stall_inst_tlb.attr.attr,
+ &armv7_event_attr_c2_cache_tag.attr.attr,
+ &armv7_event_attr_c3_cache_data.attr.attr,
+ &armv7_event_attr_c4_cache_btac.attr.attr,
+ &armv7_event_attr_ca_local_cluster_snoop.attr.attr,
+ &armv7_event_attr_d3_busy_lsu.attr.attr,
+ &armv7_event_attr_d8_busy_lsi.attr.attr,
+ &armv7_event_attr_d9_busy_dpi.attr.attr,
+ &armv7_event_attr_da_busy_dei.attr.attr,
+ &armv7_event_attr_db_neon_cond_fail.attr.attr,
+ &armv7_event_attr_dc_trap_hv.attr.attr,
+ &armv7_event_attr_de_ptm_extout0.attr.attr,
+ &armv7_event_attr_df_ptm_extout1.attr.attr,
+ &armv7_event_attr_e0_mmu_walk.attr.attr,
+ &armv7_event_attr_e1_mmu_s1_walk.attr.attr,
+ &armv7_event_attr_e2_mmu_s2_walk.attr.attr,
+ &armv7_event_attr_e3_mmu_lsu_walk.attr.attr,
+ &armv7_event_attr_e4_mmu_inst_walk.attr.attr,
+ &armv7_event_attr_e5_mmu_pre_walk.attr.attr,
+ &armv7_event_attr_e6_mmu_cp15_walk.attr.attr,
+ &armv7_event_attr_e7_tlb_pld_refill.attr.attr,
+ &armv7_event_attr_e8_tlb_cp15_refill.attr.attr,
+ &armv7_event_attr_e9_tlb_flush.attr.attr,
+ &armv7_event_attr_ea_tlb_access.attr.attr,
+ &armv7_event_attr_eb_tlb_miss.attr.attr,
+ NULL
+};
+
+static struct attribute_group armv7_a17_events_attr_group = {
+ .name = "events",
+ .attrs = armv7_a17_event_attrs,
+};
+
+static const struct attribute_group *armv7_a17_attr_groups[] = {
+ &armv7_a17_events_attr_group,
+ NULL
+};
+
/*
* Perf Events' indices
*/
@@ -1085,6 +1695,7 @@ static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
armv7pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a8";
cpu_pmu->map_event = armv7_a8_map_event;
+ cpu_pmu->pmu.attr_groups = armv7_a8_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1093,6 +1704,7 @@ static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
armv7pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a9";
cpu_pmu->map_event = armv7_a9_map_event;
+ cpu_pmu->pmu.attr_groups = armv7_a9_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1101,6 +1713,7 @@ static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
armv7pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a5";
cpu_pmu->map_event = armv7_a5_map_event;
+ cpu_pmu->pmu.attr_groups = armv7_a5_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1110,6 +1723,7 @@ static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->name = "armv7_cortex_a15";
cpu_pmu->map_event = armv7_a15_map_event;
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->pmu.attr_groups = armv7_a15_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1119,6 +1733,7 @@ static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->name = "armv7_cortex_a7";
cpu_pmu->map_event = armv7_a7_map_event;
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->pmu.attr_groups = armv7_a7_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1128,6 +1743,7 @@ static int armv7_a12_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->name = "armv7_cortex_a12";
cpu_pmu->map_event = armv7_a12_map_event;
cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
+ cpu_pmu->pmu.attr_groups = armv7_a17_attr_groups;
return armv7_probe_num_events(cpu_pmu);
}
@@ -1135,6 +1751,7 @@ static int armv7_a17_pmu_init(struct arm_pmu *cpu_pmu)
{
int ret = armv7_a12_pmu_init(cpu_pmu);
cpu_pmu->name = "armv7_cortex_a17";
+ cpu_pmu->pmu.attr_groups = armv7_a17_attr_groups;
return ret;
}
--
2.1.4
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-08-04 0:15 ` Drew Richardson
@ 2015-08-17 20:58 ` Drew Richardson
-1 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-08-17 20:58 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Will Deacon, Russell King, linux-kernel, linux-arm-kernel
Cc: Wade Cherry
On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> Add additional information about hardware events to make counters self
> describing. This makes the hardware PMUs easier to use as perf list
> contains the possible events instead of users having to refer to
> documentation like the ARM TRMs. This could also allow tools like
> oprofile to support PMUs without requiring an update.
>
> Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> ---
> arch/arm/kernel/perf_event.c | 1 +
> arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 618 insertions(+)
Any concerns with merging this?
Thanks,
Drew
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-08-17 20:58 ` Drew Richardson
0 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-08-17 20:58 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> Add additional information about hardware events to make counters self
> describing. This makes the hardware PMUs easier to use as perf list
> contains the possible events instead of users having to refer to
> documentation like the ARM TRMs. This could also allow tools like
> oprofile to support PMUs without requiring an update.
>
> Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> ---
> arch/arm/kernel/perf_event.c | 1 +
> arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 618 insertions(+)
Any concerns with merging this?
Thanks,
Drew
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-08-26 16:51 ` Will Deacon
@ 2015-08-17 21:40 ` Drew Richardson
-1 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-08-17 21:40 UTC (permalink / raw)
To: Will Deacon
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Russell King, linux-kernel, linux-arm-kernel, Wade Cherry
On Wed, Aug 26, 2015 at 05:51:49PM +0100, Will Deacon wrote:
> On Mon, Aug 17, 2015 at 09:58:09PM +0100, Drew Richardson wrote:
> > On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> > > Add additional information about hardware events to make counters self
> > > describing. This makes the hardware PMUs easier to use as perf list
> > > contains the possible events instead of users having to refer to
> > > documentation like the ARM TRMs. This could also allow tools like
> > > oprofile to support PMUs without requiring an update.
> > >
> > > Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> > > ---
> > > arch/arm/kernel/perf_event.c | 1 +
> > > arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 618 insertions(+)
> >
> > Any concerns with merging this?
>
> We should revisit this after the merge window (since the ARM perf code is
> moving out to drivers/)
Not a problem
> but I do have reservations about putting all these
> strings into the kernel. Why can't we put this into something like libpfm
> instead?
>
> Will
>
My intent is to make it easier for people to use hardware counters on
ARM, particularly with new CPUs. Currently, the developer of the tool
needs to extract the event information from the ARM TRMs, add it to
their tool and make a new release. This work is done by multiple
tools, for example for the Cortex-A15:
http://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/lib/events/arm_cortex_a15_events.h
http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/arm/armv7-ca15/events
https://github.com/ARM-software/gator/blob/master/daemon/events-Cortex-A15.xml
There are likely more tools, these are the ones I could easily
find. Note that the new ARM Cortex-A72 isn't supported by most of
them. And the perf command line tool doesn't have any of this.
Once the tool supports the new CPUs events the user needs to make sure
they're running a recent version of the tool that contains these
events for their new ARM CPU. Technically the user could add the event
information themselves and upstream the change, but not all users will
do this.
So my suggestion to solve the problem is that the kernel can have the
list of events as proposed in the patch. This is already done for some
PMUs like arm-ccn and arm-cci. If the tool doesn't support the
particular CPU, they can fall back to the event list provided by the
kernel. There will be some information missing like user-friendly
descriptions of the events, but it's hopefully enough that users can
do what they need to do and update their tool at a later time.
I'd be glad to wrap this all in a config option so users can disable
it to reduce bloat. Perhaps there is some other central location
outside the kernel that could store this information?
Thanks,
Drew
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-08-17 21:40 ` Drew Richardson
0 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-08-17 21:40 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 26, 2015 at 05:51:49PM +0100, Will Deacon wrote:
> On Mon, Aug 17, 2015 at 09:58:09PM +0100, Drew Richardson wrote:
> > On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> > > Add additional information about hardware events to make counters self
> > > describing. This makes the hardware PMUs easier to use as perf list
> > > contains the possible events instead of users having to refer to
> > > documentation like the ARM TRMs. This could also allow tools like
> > > oprofile to support PMUs without requiring an update.
> > >
> > > Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> > > ---
> > > arch/arm/kernel/perf_event.c | 1 +
> > > arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 618 insertions(+)
> >
> > Any concerns with merging this?
>
> We should revisit this after the merge window (since the ARM perf code is
> moving out to drivers/)
Not a problem
> but I do have reservations about putting all these
> strings into the kernel. Why can't we put this into something like libpfm
> instead?
>
> Will
>
My intent is to make it easier for people to use hardware counters on
ARM, particularly with new CPUs. Currently, the developer of the tool
needs to extract the event information from the ARM TRMs, add it to
their tool and make a new release. This work is done by multiple
tools, for example for the Cortex-A15:
http://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/lib/events/arm_cortex_a15_events.h
http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/arm/armv7-ca15/events
https://github.com/ARM-software/gator/blob/master/daemon/events-Cortex-A15.xml
There are likely more tools, these are the ones I could easily
find. Note that the new ARM Cortex-A72 isn't supported by most of
them. And the perf command line tool doesn't have any of this.
Once the tool supports the new CPUs events the user needs to make sure
they're running a recent version of the tool that contains these
events for their new ARM CPU. Technically the user could add the event
information themselves and upstream the change, but not all users will
do this.
So my suggestion to solve the problem is that the kernel can have the
list of events as proposed in the patch. This is already done for some
PMUs like arm-ccn and arm-cci. If the tool doesn't support the
particular CPU, they can fall back to the event list provided by the
kernel. There will be some information missing like user-friendly
descriptions of the events, but it's hopefully enough that users can
do what they need to do and update their tool at a later time.
I'd be glad to wrap this all in a config option so users can disable
it to reduce bloat. Perhaps there is some other central location
outside the kernel that could store this information?
Thanks,
Drew
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-08-17 20:58 ` Drew Richardson
@ 2015-08-26 16:51 ` Will Deacon
-1 siblings, 0 replies; 22+ messages in thread
From: Will Deacon @ 2015-08-26 16:51 UTC (permalink / raw)
To: Drew Richardson
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Russell King, linux-kernel, linux-arm-kernel, Wade Cherry
On Mon, Aug 17, 2015 at 09:58:09PM +0100, Drew Richardson wrote:
> On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> > Add additional information about hardware events to make counters self
> > describing. This makes the hardware PMUs easier to use as perf list
> > contains the possible events instead of users having to refer to
> > documentation like the ARM TRMs. This could also allow tools like
> > oprofile to support PMUs without requiring an update.
> >
> > Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> > ---
> > arch/arm/kernel/perf_event.c | 1 +
> > arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 618 insertions(+)
>
> Any concerns with merging this?
We should revisit this after the merge window (since the ARM perf code is
moving out to drivers/), but I do have reservations about putting all these
strings into the kernel. Why can't we put this into something like libpfm
instead?
Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-08-26 16:51 ` Will Deacon
0 siblings, 0 replies; 22+ messages in thread
From: Will Deacon @ 2015-08-26 16:51 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 17, 2015 at 09:58:09PM +0100, Drew Richardson wrote:
> On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> > Add additional information about hardware events to make counters self
> > describing. This makes the hardware PMUs easier to use as perf list
> > contains the possible events instead of users having to refer to
> > documentation like the ARM TRMs. This could also allow tools like
> > oprofile to support PMUs without requiring an update.
> >
> > Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> > ---
> > arch/arm/kernel/perf_event.c | 1 +
> > arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 618 insertions(+)
>
> Any concerns with merging this?
We should revisit this after the merge window (since the ARM perf code is
moving out to drivers/), but I do have reservations about putting all these
strings into the kernel. Why can't we put this into something like libpfm
instead?
Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-08-17 21:40 ` Drew Richardson
@ 2015-09-24 17:31 ` Drew Richardson
-1 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-09-24 17:31 UTC (permalink / raw)
To: Will Deacon
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Russell King, linux-kernel, linux-arm-kernel, Wade Cherry
On Mon, Aug 17, 2015 at 10:40:35PM +0100, Drew Richardson wrote:
> On Wed, Aug 26, 2015 at 05:51:49PM +0100, Will Deacon wrote:
> > On Mon, Aug 17, 2015 at 09:58:09PM +0100, Drew Richardson wrote:
> > > On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> > > > Add additional information about hardware events to make counters self
> > > > describing. This makes the hardware PMUs easier to use as perf list
> > > > contains the possible events instead of users having to refer to
> > > > documentation like the ARM TRMs. This could also allow tools like
> > > > oprofile to support PMUs without requiring an update.
> > > >
> > > > Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> > > > ---
> > > > arch/arm/kernel/perf_event.c | 1 +
> > > > arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 618 insertions(+)
> > >
> > > Any concerns with merging this?
> >
> > We should revisit this after the merge window (since the ARM perf code is
> > moving out to drivers/)
>
> Not a problem
>
> > but I do have reservations about putting all these
> > strings into the kernel. Why can't we put this into something like libpfm
> > instead?
> >
> > Will
> >
>
> My intent is to make it easier for people to use hardware counters on
> ARM, particularly with new CPUs. Currently, the developer of the tool
> needs to extract the event information from the ARM TRMs, add it to
> their tool and make a new release. This work is done by multiple
> tools, for example for the Cortex-A15:
>
> http://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/lib/events/arm_cortex_a15_events.h
> http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/arm/armv7-ca15/events
> https://github.com/ARM-software/gator/blob/master/daemon/events-Cortex-A15.xml
>
> There are likely more tools, these are the ones I could easily
> find. Note that the new ARM Cortex-A72 isn't supported by most of
> them. And the perf command line tool doesn't have any of this.
>
> Once the tool supports the new CPUs events the user needs to make sure
> they're running a recent version of the tool that contains these
> events for their new ARM CPU. Technically the user could add the event
> information themselves and upstream the change, but not all users will
> do this.
>
> So my suggestion to solve the problem is that the kernel can have the
> list of events as proposed in the patch. This is already done for some
> PMUs like arm-ccn and arm-cci. If the tool doesn't support the
> particular CPU, they can fall back to the event list provided by the
> kernel. There will be some information missing like user-friendly
> descriptions of the events, but it's hopefully enough that users can
> do what they need to do and update their tool at a later time.
>
> I'd be glad to wrap this all in a config option so users can disable
> it to reduce bloat. Perhaps there is some other central location
> outside the kernel that could store this information?
>
> Thanks,
>
> Drew
Will,
Have you had a chance to review this again? I also noticed that my x86
machines have something similar, although not as few events as I'm
proposing to add.
$ ls /sys/bus/event_source/devices/cpu/events/
cycles-ct el-capacity el-start tx-abort tx-conflict
cycles-t el-commit mem-loads tx-capacity tx-start
el-abort el-conflict mem-stores tx-commit
Thanks,
Drew
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-09-24 17:31 ` Drew Richardson
0 siblings, 0 replies; 22+ messages in thread
From: Drew Richardson @ 2015-09-24 17:31 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 17, 2015 at 10:40:35PM +0100, Drew Richardson wrote:
> On Wed, Aug 26, 2015 at 05:51:49PM +0100, Will Deacon wrote:
> > On Mon, Aug 17, 2015 at 09:58:09PM +0100, Drew Richardson wrote:
> > > On Tue, Aug 04, 2015 at 01:15:23AM +0100, Drew Richardson wrote:
> > > > Add additional information about hardware events to make counters self
> > > > describing. This makes the hardware PMUs easier to use as perf list
> > > > contains the possible events instead of users having to refer to
> > > > documentation like the ARM TRMs. This could also allow tools like
> > > > oprofile to support PMUs without requiring an update.
> > > >
> > > > Signed-off-by: Drew Richardson <drew.richardson@arm.com>
> > > > ---
> > > > arch/arm/kernel/perf_event.c | 1 +
> > > > arch/arm/kernel/perf_event_v7.c | 617 ++++++++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 618 insertions(+)
> > >
> > > Any concerns with merging this?
> >
> > We should revisit this after the merge window (since the ARM perf code is
> > moving out to drivers/)
>
> Not a problem
>
> > but I do have reservations about putting all these
> > strings into the kernel. Why can't we put this into something like libpfm
> > instead?
> >
> > Will
> >
>
> My intent is to make it easier for people to use hardware counters on
> ARM, particularly with new CPUs. Currently, the developer of the tool
> needs to extract the event information from the ARM TRMs, add it to
> their tool and make a new release. This work is done by multiple
> tools, for example for the Cortex-A15:
>
> http://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/lib/events/arm_cortex_a15_events.h
> http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/arm/armv7-ca15/events
> https://github.com/ARM-software/gator/blob/master/daemon/events-Cortex-A15.xml
>
> There are likely more tools, these are the ones I could easily
> find. Note that the new ARM Cortex-A72 isn't supported by most of
> them. And the perf command line tool doesn't have any of this.
>
> Once the tool supports the new CPUs events the user needs to make sure
> they're running a recent version of the tool that contains these
> events for their new ARM CPU. Technically the user could add the event
> information themselves and upstream the change, but not all users will
> do this.
>
> So my suggestion to solve the problem is that the kernel can have the
> list of events as proposed in the patch. This is already done for some
> PMUs like arm-ccn and arm-cci. If the tool doesn't support the
> particular CPU, they can fall back to the event list provided by the
> kernel. There will be some information missing like user-friendly
> descriptions of the events, but it's hopefully enough that users can
> do what they need to do and update their tool at a later time.
>
> I'd be glad to wrap this all in a config option so users can disable
> it to reduce bloat. Perhaps there is some other central location
> outside the kernel that could store this information?
>
> Thanks,
>
> Drew
Will,
Have you had a chance to review this again? I also noticed that my x86
machines have something similar, although not as few events as I'm
proposing to add.
$ ls /sys/bus/event_source/devices/cpu/events/
cycles-ct el-capacity el-start tx-abort tx-conflict
cycles-t el-commit mem-loads tx-capacity tx-start
el-abort el-conflict mem-stores tx-commit
Thanks,
Drew
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-08-17 21:40 ` Drew Richardson
@ 2015-09-24 17:52 ` Will Deacon
-1 siblings, 0 replies; 22+ messages in thread
From: Will Deacon @ 2015-09-24 17:52 UTC (permalink / raw)
To: Drew Richardson
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Russell King, linux-kernel, linux-arm-kernel, Wade Cherry
Hi Drew,
On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> On Wed, Aug 26, 2015 at 05:51:49PM +0100, Will Deacon wrote:
> > but I do have reservations about putting all these
> > strings into the kernel. Why can't we put this into something like libpfm
> > instead?
> >
>
> My intent is to make it easier for people to use hardware counters on
> ARM, particularly with new CPUs. Currently, the developer of the tool
> needs to extract the event information from the ARM TRMs, add it to
> their tool and make a new release. This work is done by multiple
> tools, for example for the Cortex-A15:
>
> http://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/lib/events/arm_cortex_a15_events.h
> http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/arm/armv7-ca15/events
> https://github.com/ARM-software/gator/blob/master/daemon/events-Cortex-A15.xml
>
> There are likely more tools, these are the ones I could easily
> find. Note that the new ARM Cortex-A72 isn't supported by most of
> them. And the perf command line tool doesn't have any of this.
So to repeat the question, why can't libpfm be used instead? It doesn't seem
like it would be too much work to integrate that with the perf tool.
> Once the tool supports the new CPUs events the user needs to make sure
> they're running a recent version of the tool that contains these
> events for their new ARM CPU. Technically the user could add the event
> information themselves and upstream the change, but not all users will
> do this.
How does moving this into the kernel remove the need to upstream new
event descriptions?
> So my suggestion to solve the problem is that the kernel can have the
> list of events as proposed in the patch.
Sorry, but I just don't buy this argument. Your problem is that the user
needs to be running an up-to-date perf tool, but with your proposed
solution, you're asking them to update the *kernel* instead, which is
(unfortunately) one of the hardest pieces of software to upgrade on a
typical ARM platform.
> This is already done for some PMUs like arm-ccn and arm-cci. If the tool
> doesn't support the particular CPU, they can fall back to the event list
> provided by the kernel. There will be some information missing like
> user-friendly descriptions of the events, but it's hopefully enough that
> users can do what they need to do and update their tool at a later time.
The problem is somewhat simpler for system PMUs, which don't suffer from
the variations that we encounter on the CPU side and are also less uniform.
Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-09-24 17:52 ` Will Deacon
0 siblings, 0 replies; 22+ messages in thread
From: Will Deacon @ 2015-09-24 17:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi Drew,
On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> On Wed, Aug 26, 2015 at 05:51:49PM +0100, Will Deacon wrote:
> > but I do have reservations about putting all these
> > strings into the kernel. Why can't we put this into something like libpfm
> > instead?
> >
>
> My intent is to make it easier for people to use hardware counters on
> ARM, particularly with new CPUs. Currently, the developer of the tool
> needs to extract the event information from the ARM TRMs, add it to
> their tool and make a new release. This work is done by multiple
> tools, for example for the Cortex-A15:
>
> http://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/lib/events/arm_cortex_a15_events.h
> http://sourceforge.net/p/oprofile/oprofile/ci/master/tree/events/arm/armv7-ca15/events
> https://github.com/ARM-software/gator/blob/master/daemon/events-Cortex-A15.xml
>
> There are likely more tools, these are the ones I could easily
> find. Note that the new ARM Cortex-A72 isn't supported by most of
> them. And the perf command line tool doesn't have any of this.
So to repeat the question, why can't libpfm be used instead? It doesn't seem
like it would be too much work to integrate that with the perf tool.
> Once the tool supports the new CPUs events the user needs to make sure
> they're running a recent version of the tool that contains these
> events for their new ARM CPU. Technically the user could add the event
> information themselves and upstream the change, but not all users will
> do this.
How does moving this into the kernel remove the need to upstream new
event descriptions?
> So my suggestion to solve the problem is that the kernel can have the
> list of events as proposed in the patch.
Sorry, but I just don't buy this argument. Your problem is that the user
needs to be running an up-to-date perf tool, but with your proposed
solution, you're asking them to update the *kernel* instead, which is
(unfortunately) one of the hardest pieces of software to upgrade on a
typical ARM platform.
> This is already done for some PMUs like arm-ccn and arm-cci. If the tool
> doesn't support the particular CPU, they can fall back to the event list
> provided by the kernel. There will be some information missing like
> user-friendly descriptions of the events, but it's hopefully enough that
> users can do what they need to do and update their tool at a later time.
The problem is somewhat simpler for system PMUs, which don't suffer from
the variations that we encounter on the CPU side and are also less uniform.
Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-09-24 17:52 ` Will Deacon
@ 2015-10-07 11:20 ` Will Deacon
-1 siblings, 0 replies; 22+ messages in thread
From: Will Deacon @ 2015-10-07 11:20 UTC (permalink / raw)
To: Drew Richardson
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Russell King, linux-kernel, linux-arm-kernel, Wade Cherry
Hi again, Drew,
On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> > So my suggestion to solve the problem is that the kernel can have the
> > list of events as proposed in the patch.
>
> Sorry, but I just don't buy this argument. Your problem is that the user
> needs to be running an up-to-date perf tool, but with your proposed
> solution, you're asking them to update the *kernel* instead, which is
> (unfortunately) one of the hardest pieces of software to upgrade on a
> typical ARM platform.
I've spent some time thinking about this and, actually, it makes sense
to do this for the architected events. These event numbers are guaranteed
to be portable between CPUs, so if we expose those through sysfs then
we don't have this dependency on updating the kernel for newer cores
(well, once the initial period without your patch has expired). It's the
noon-portable, micro-architectural events that I object to.
So how about you roll a new version of this patch just exposing the
architected events and making use of the macros in perf_event.h to make
it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
since we're moving over to the code in drivers/perf/. Hopefully these
will appear on the arm64 for-next/core branch shortly.
Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-10-07 11:20 ` Will Deacon
0 siblings, 0 replies; 22+ messages in thread
From: Will Deacon @ 2015-10-07 11:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi again, Drew,
On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> > So my suggestion to solve the problem is that the kernel can have the
> > list of events as proposed in the patch.
>
> Sorry, but I just don't buy this argument. Your problem is that the user
> needs to be running an up-to-date perf tool, but with your proposed
> solution, you're asking them to update the *kernel* instead, which is
> (unfortunately) one of the hardest pieces of software to upgrade on a
> typical ARM platform.
I've spent some time thinking about this and, actually, it makes sense
to do this for the architected events. These event numbers are guaranteed
to be portable between CPUs, so if we expose those through sysfs then
we don't have this dependency on updating the kernel for newer cores
(well, once the initial period without your patch has expired). It's the
noon-portable, micro-architectural events that I object to.
So how about you roll a new version of this patch just exposing the
architected events and making use of the macros in perf_event.h to make
it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
since we're moving over to the code in drivers/perf/. Hopefully these
will appear on the arm64 for-next/core branch shortly.
Will
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-10-07 11:20 ` Will Deacon
@ 2015-10-27 15:46 ` Christopher Covington
-1 siblings, 0 replies; 22+ messages in thread
From: Christopher Covington @ 2015-10-27 15:46 UTC (permalink / raw)
To: Will Deacon, Drew Richardson
Cc: Russell King, Peter Zijlstra, linux-kernel,
Arnaldo Carvalho de Melo, Ingo Molnar, Wade Cherry,
linux-arm-kernel
On 10/07/2015 07:20 AM, Will Deacon wrote:
> Hi again, Drew,
>
> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
>>> So my suggestion to solve the problem is that the kernel can have the
>>> list of events as proposed in the patch.
>>
>> Sorry, but I just don't buy this argument. Your problem is that the user
>> needs to be running an up-to-date perf tool, but with your proposed
>> solution, you're asking them to update the *kernel* instead, which is
>> (unfortunately) one of the hardest pieces of software to upgrade on a
>> typical ARM platform.
>
> I've spent some time thinking about this and, actually, it makes sense
> to do this for the architected events. These event numbers are guaranteed
> to be portable between CPUs, so if we expose those through sysfs then
> we don't have this dependency on updating the kernel for newer cores
> (well, once the initial period without your patch has expired). It's the
> noon-portable, micro-architectural events that I object to.
>
> So how about you roll a new version of this patch just exposing the
> architected events and making use of the macros in perf_event.h to make
> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
>
> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> since we're moving over to the code in drivers/perf/. Hopefully these
> will appear on the arm64 for-next/core branch shortly.
Have you considered using OF/ACPI to describe this aspect of the hardware?
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-10-27 15:46 ` Christopher Covington
0 siblings, 0 replies; 22+ messages in thread
From: Christopher Covington @ 2015-10-27 15:46 UTC (permalink / raw)
To: linux-arm-kernel
On 10/07/2015 07:20 AM, Will Deacon wrote:
> Hi again, Drew,
>
> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
>>> So my suggestion to solve the problem is that the kernel can have the
>>> list of events as proposed in the patch.
>>
>> Sorry, but I just don't buy this argument. Your problem is that the user
>> needs to be running an up-to-date perf tool, but with your proposed
>> solution, you're asking them to update the *kernel* instead, which is
>> (unfortunately) one of the hardest pieces of software to upgrade on a
>> typical ARM platform.
>
> I've spent some time thinking about this and, actually, it makes sense
> to do this for the architected events. These event numbers are guaranteed
> to be portable between CPUs, so if we expose those through sysfs then
> we don't have this dependency on updating the kernel for newer cores
> (well, once the initial period without your patch has expired). It's the
> noon-portable, micro-architectural events that I object to.
>
> So how about you roll a new version of this patch just exposing the
> architected events and making use of the macros in perf_event.h to make
> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
>
> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> since we're moving over to the code in drivers/perf/. Hopefully these
> will appear on the arm64 for-next/core branch shortly.
Have you considered using OF/ACPI to describe this aspect of the hardware?
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-10-27 15:46 ` Christopher Covington
@ 2015-10-27 16:04 ` Mark Rutland
-1 siblings, 0 replies; 22+ messages in thread
From: Mark Rutland @ 2015-10-27 16:04 UTC (permalink / raw)
To: Christopher Covington
Cc: Will Deacon, Drew Richardson, Russell King, Peter Zijlstra,
linux-kernel, Arnaldo Carvalho de Melo, Ingo Molnar, Wade Cherry,
linux-arm-kernel
On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
> On 10/07/2015 07:20 AM, Will Deacon wrote:
> > Hi again, Drew,
> >
> > On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> >> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> >>> So my suggestion to solve the problem is that the kernel can have the
> >>> list of events as proposed in the patch.
> >>
> >> Sorry, but I just don't buy this argument. Your problem is that the user
> >> needs to be running an up-to-date perf tool, but with your proposed
> >> solution, you're asking them to update the *kernel* instead, which is
> >> (unfortunately) one of the hardest pieces of software to upgrade on a
> >> typical ARM platform.
> >
> > I've spent some time thinking about this and, actually, it makes sense
> > to do this for the architected events. These event numbers are guaranteed
> > to be portable between CPUs, so if we expose those through sysfs then
> > we don't have this dependency on updating the kernel for newer cores
> > (well, once the initial period without your patch has expired). It's the
> > noon-portable, micro-architectural events that I object to.
> >
> > So how about you roll a new version of this patch just exposing the
> > architected events and making use of the macros in perf_event.h to make
> > it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> >
> > Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> > since we're moving over to the code in drivers/perf/. Hopefully these
> > will appear on the arm64 for-next/core branch shortly.
>
> Have you considered using OF/ACPI to describe this aspect of the hardware?
FW-provided data structures are going to be harder to upgrade than the
kernel, so the same argument applies as with placing this data in the
kernel (if anything, more strongly).
Thanks,
Mark.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-10-27 16:04 ` Mark Rutland
0 siblings, 0 replies; 22+ messages in thread
From: Mark Rutland @ 2015-10-27 16:04 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
> On 10/07/2015 07:20 AM, Will Deacon wrote:
> > Hi again, Drew,
> >
> > On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> >> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> >>> So my suggestion to solve the problem is that the kernel can have the
> >>> list of events as proposed in the patch.
> >>
> >> Sorry, but I just don't buy this argument. Your problem is that the user
> >> needs to be running an up-to-date perf tool, but with your proposed
> >> solution, you're asking them to update the *kernel* instead, which is
> >> (unfortunately) one of the hardest pieces of software to upgrade on a
> >> typical ARM platform.
> >
> > I've spent some time thinking about this and, actually, it makes sense
> > to do this for the architected events. These event numbers are guaranteed
> > to be portable between CPUs, so if we expose those through sysfs then
> > we don't have this dependency on updating the kernel for newer cores
> > (well, once the initial period without your patch has expired). It's the
> > noon-portable, micro-architectural events that I object to.
> >
> > So how about you roll a new version of this patch just exposing the
> > architected events and making use of the macros in perf_event.h to make
> > it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> >
> > Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> > since we're moving over to the code in drivers/perf/. Hopefully these
> > will appear on the arm64 for-next/core branch shortly.
>
> Have you considered using OF/ACPI to describe this aspect of the hardware?
FW-provided data structures are going to be harder to upgrade than the
kernel, so the same argument applies as with placing this data in the
kernel (if anything, more strongly).
Thanks,
Mark.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-10-27 16:04 ` Mark Rutland
@ 2015-10-28 14:14 ` Christopher Covington
-1 siblings, 0 replies; 22+ messages in thread
From: Christopher Covington @ 2015-10-28 14:14 UTC (permalink / raw)
To: Mark Rutland
Cc: Will Deacon, Drew Richardson, Russell King, Peter Zijlstra,
linux-kernel, Arnaldo Carvalho de Melo, Ingo Molnar, Wade Cherry,
linux-arm-kernel
On 10/27/2015 12:04 PM, Mark Rutland wrote:
> On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
>> On 10/07/2015 07:20 AM, Will Deacon wrote:
>>> Hi again, Drew,
>>>
>>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>>>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
>>>>> So my suggestion to solve the problem is that the kernel can have the
>>>>> list of events as proposed in the patch.
>>>>
>>>> Sorry, but I just don't buy this argument. Your problem is that the user
>>>> needs to be running an up-to-date perf tool, but with your proposed
>>>> solution, you're asking them to update the *kernel* instead, which is
>>>> (unfortunately) one of the hardest pieces of software to upgrade on a
>>>> typical ARM platform.
>>>
>>> I've spent some time thinking about this and, actually, it makes sense
>>> to do this for the architected events. These event numbers are guaranteed
>>> to be portable between CPUs, so if we expose those through sysfs then
>>> we don't have this dependency on updating the kernel for newer cores
>>> (well, once the initial period without your patch has expired). It's the
>>> noon-portable, micro-architectural events that I object to.
>>>
>>> So how about you roll a new version of this patch just exposing the
>>> architected events and making use of the macros in perf_event.h to make
>>> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
>>>
>>> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
>>> since we're moving over to the code in drivers/perf/. Hopefully these
>>> will appear on the arm64 for-next/core branch shortly.
>>
>> Have you considered using OF/ACPI to describe this aspect of the hardware?
>
> FW-provided data structures are going to be harder to upgrade than the
> kernel, so the same argument applies as with placing this data in the
> kernel (if anything, more strongly).
A convenient place for workarounds is great, when necessary, but I don't see
why Plan A for hardware description should be anything other than standardized
hardware description mechanisms.
Why are you eager to inflate the expectations of firmware when it comes to
power state coordination but reluctant to rely on firmware for describing
performance monitor events?
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-10-28 14:14 ` Christopher Covington
0 siblings, 0 replies; 22+ messages in thread
From: Christopher Covington @ 2015-10-28 14:14 UTC (permalink / raw)
To: linux-arm-kernel
On 10/27/2015 12:04 PM, Mark Rutland wrote:
> On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
>> On 10/07/2015 07:20 AM, Will Deacon wrote:
>>> Hi again, Drew,
>>>
>>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>>>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
>>>>> So my suggestion to solve the problem is that the kernel can have the
>>>>> list of events as proposed in the patch.
>>>>
>>>> Sorry, but I just don't buy this argument. Your problem is that the user
>>>> needs to be running an up-to-date perf tool, but with your proposed
>>>> solution, you're asking them to update the *kernel* instead, which is
>>>> (unfortunately) one of the hardest pieces of software to upgrade on a
>>>> typical ARM platform.
>>>
>>> I've spent some time thinking about this and, actually, it makes sense
>>> to do this for the architected events. These event numbers are guaranteed
>>> to be portable between CPUs, so if we expose those through sysfs then
>>> we don't have this dependency on updating the kernel for newer cores
>>> (well, once the initial period without your patch has expired). It's the
>>> noon-portable, micro-architectural events that I object to.
>>>
>>> So how about you roll a new version of this patch just exposing the
>>> architected events and making use of the macros in perf_event.h to make
>>> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
>>>
>>> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
>>> since we're moving over to the code in drivers/perf/. Hopefully these
>>> will appear on the arm64 for-next/core branch shortly.
>>
>> Have you considered using OF/ACPI to describe this aspect of the hardware?
>
> FW-provided data structures are going to be harder to upgrade than the
> kernel, so the same argument applies as with placing this data in the
> kernel (if anything, more strongly).
A convenient place for workarounds is great, when necessary, but I don't see
why Plan A for hardware description should be anything other than standardized
hardware description mechanisms.
Why are you eager to inflate the expectations of firmware when it comes to
power state coordination but reluctant to rely on firmware for describing
performance monitor events?
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] arm: perf: Add event descriptions
2015-10-28 14:14 ` Christopher Covington
@ 2015-10-28 14:29 ` Mark Rutland
-1 siblings, 0 replies; 22+ messages in thread
From: Mark Rutland @ 2015-10-28 14:29 UTC (permalink / raw)
To: Christopher Covington
Cc: Will Deacon, Drew Richardson, Russell King, Peter Zijlstra,
linux-kernel, Arnaldo Carvalho de Melo, Ingo Molnar, Wade Cherry,
linux-arm-kernel
On Wed, Oct 28, 2015 at 10:14:24AM -0400, Christopher Covington wrote:
> On 10/27/2015 12:04 PM, Mark Rutland wrote:
> > On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
> >> On 10/07/2015 07:20 AM, Will Deacon wrote:
> >>> Hi again, Drew,
> >>>
> >>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> >>>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> >>>>> So my suggestion to solve the problem is that the kernel can have the
> >>>>> list of events as proposed in the patch.
> >>>>
> >>>> Sorry, but I just don't buy this argument. Your problem is that the user
> >>>> needs to be running an up-to-date perf tool, but with your proposed
> >>>> solution, you're asking them to update the *kernel* instead, which is
> >>>> (unfortunately) one of the hardest pieces of software to upgrade on a
> >>>> typical ARM platform.
> >>>
> >>> I've spent some time thinking about this and, actually, it makes sense
> >>> to do this for the architected events. These event numbers are guaranteed
> >>> to be portable between CPUs, so if we expose those through sysfs then
> >>> we don't have this dependency on updating the kernel for newer cores
> >>> (well, once the initial period without your patch has expired). It's the
> >>> noon-portable, micro-architectural events that I object to.
> >>>
> >>> So how about you roll a new version of this patch just exposing the
> >>> architected events and making use of the macros in perf_event.h to make
> >>> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> >>>
> >>> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> >>> since we're moving over to the code in drivers/perf/. Hopefully these
> >>> will appear on the arm64 for-next/core branch shortly.
> >>
> >> Have you considered using OF/ACPI to describe this aspect of the hardware?
> >
> > FW-provided data structures are going to be harder to upgrade than the
> > kernel, so the same argument applies as with placing this data in the
> > kernel (if anything, more strongly).
>
> A convenient place for workarounds is great, when necessary, but I don't see
> why Plan A for hardware description should be anything other than standardized
> hardware description mechanisms.
>
> Why are you eager to inflate the expectations of firmware when it comes to
> power state coordination but reluctant to rely on firmware for describing
> performance monitor events?
Firmware has the responsibility to describe the integration details of
the PMU (the interrupt routing), because that varies between platforms.
The set of supported events does not, for a given PMU (e.g. the events
supported by a Cortex-A57 are the same regardless of whether it's
integrated an ARM Juno or an AMD Seattle), and are effectively part of
the programming model of the device.
Power state coordination is very much platform specific; and is not
comparable.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH] arm: perf: Add event descriptions
@ 2015-10-28 14:29 ` Mark Rutland
0 siblings, 0 replies; 22+ messages in thread
From: Mark Rutland @ 2015-10-28 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 28, 2015 at 10:14:24AM -0400, Christopher Covington wrote:
> On 10/27/2015 12:04 PM, Mark Rutland wrote:
> > On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
> >> On 10/07/2015 07:20 AM, Will Deacon wrote:
> >>> Hi again, Drew,
> >>>
> >>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
> >>>> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote:
> >>>>> So my suggestion to solve the problem is that the kernel can have the
> >>>>> list of events as proposed in the patch.
> >>>>
> >>>> Sorry, but I just don't buy this argument. Your problem is that the user
> >>>> needs to be running an up-to-date perf tool, but with your proposed
> >>>> solution, you're asking them to update the *kernel* instead, which is
> >>>> (unfortunately) one of the hardest pieces of software to upgrade on a
> >>>> typical ARM platform.
> >>>
> >>> I've spent some time thinking about this and, actually, it makes sense
> >>> to do this for the architected events. These event numbers are guaranteed
> >>> to be portable between CPUs, so if we expose those through sysfs then
> >>> we don't have this dependency on updating the kernel for newer cores
> >>> (well, once the initial period without your patch has expired). It's the
> >>> noon-portable, micro-architectural events that I object to.
> >>>
> >>> So how about you roll a new version of this patch just exposing the
> >>> architected events and making use of the macros in perf_event.h to make
> >>> it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)?
> >>>
> >>> Be aware that there's a fair amount of arm64 perf patches queue for 4.4,
> >>> since we're moving over to the code in drivers/perf/. Hopefully these
> >>> will appear on the arm64 for-next/core branch shortly.
> >>
> >> Have you considered using OF/ACPI to describe this aspect of the hardware?
> >
> > FW-provided data structures are going to be harder to upgrade than the
> > kernel, so the same argument applies as with placing this data in the
> > kernel (if anything, more strongly).
>
> A convenient place for workarounds is great, when necessary, but I don't see
> why Plan A for hardware description should be anything other than standardized
> hardware description mechanisms.
>
> Why are you eager to inflate the expectations of firmware when it comes to
> power state coordination but reluctant to rely on firmware for describing
> performance monitor events?
Firmware has the responsibility to describe the integration details of
the PMU (the interrupt routing), because that varies between platforms.
The set of supported events does not, for a given PMU (e.g. the events
supported by a Cortex-A57 are the same regardless of whether it's
integrated an ARM Juno or an AMD Seattle), and are effectively part of
the programming model of the device.
Power state coordination is very much platform specific; and is not
comparable.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2015-10-28 14:29 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-04 0:15 [PATCH] arm: perf: Add event descriptions Drew Richardson
2015-08-04 0:15 ` Drew Richardson
2015-08-17 20:58 ` Drew Richardson
2015-08-17 20:58 ` Drew Richardson
2015-08-26 16:51 ` Will Deacon
2015-08-26 16:51 ` Will Deacon
2015-08-17 21:40 ` Drew Richardson
2015-08-17 21:40 ` Drew Richardson
2015-09-24 17:31 ` Drew Richardson
2015-09-24 17:31 ` Drew Richardson
2015-09-24 17:52 ` Will Deacon
2015-09-24 17:52 ` Will Deacon
2015-10-07 11:20 ` Will Deacon
2015-10-07 11:20 ` Will Deacon
2015-10-27 15:46 ` Christopher Covington
2015-10-27 15:46 ` Christopher Covington
2015-10-27 16:04 ` Mark Rutland
2015-10-27 16:04 ` Mark Rutland
2015-10-28 14:14 ` Christopher Covington
2015-10-28 14:14 ` Christopher Covington
2015-10-28 14:29 ` Mark Rutland
2015-10-28 14:29 ` Mark Rutland
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.