from:"Paul Clarke"

Re: perf tools:Is there any tools to found out the max latency by irq or cpu idle

2019-04-15 Thread Paul Clarke

On 4/13/19 1:01 AM, Linhaifeng wrote:
> Sorry, the value 131081408 is just for example. Actually the result is like 
> this:
>  sqrt 2019-04-10 23:53:50: 43968
>  sqrt 2019-04-10 23:53:51: 44060
>  sqrt 2019-04-10 23:53:52: 49012
>  sqrt 2019-04-10 23:53:53: 38172
>  sqrt 2019-04-10 23:53:54: 131081408
>  sqrt 2019-04-10 23:53:55: 43600
>  sqrt 2019-04-10 23:53:56: 46704
>  sqrt 2019-04-10 23:53:57: 46880
>  sqrt 2019-04-10 23:53:58: 44332
>  ……
>  sqrt 2019-04-10 02:17:15: 136345876
>  ……
>  sqrt 2019-04-10 04:40:35: 136335644
>  ……

Given the periodicity, I'm wondering if it could be System Management 
Interrupts (SMIs)?

If so, some BIOSes have settings to mitigate, otherwise, there's not much that 
can be done, per my understanding.

PC

> -Original Message-
> From: William Cohen [mailto:wco...@redhat.com] 
> Sent: 2019年4月12日 22:06
> To: Linhaifeng ; linux-perf-us...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: perf tools:Is there any tools to found out the max latency by 
> irq or cpu idle
> 
> On 4/11/19 8:57 PM, Linhaifeng wrote:
>> Hi,
>> I have a single thread application like this:
>>
>> While (1) {
>>     start = rdtsc();
>>     sqrt (1024);  
>> 　　end = rdtsc();
>> 　　cycles = end – start;
>> 　　printf("cycles: %d-%02d-%02d %02d:%02d:%02d: %lu\n", 
>> 　　1900+timeinfo->tm_year, 1+timeinfo->tm_mon, timeinfo->tm_mday, 
>> timeinfo->tm_hour, timeinfo->tm_min, timeinfo->tm_sec,
>> 　　cycles);
>> }
>> It print the cycles of sqrt every second and run with taskset –c 1 ./sqrt.
>> The result of test is:
>>
>> sqrt 2019-04-10 23:53:50: 43968
>> sqrt 2019-04-10 23:53:51: 44060
>> sqrt 2019-04-10 23:53:52: 49012
>> sqrt 2019-04-10 23:53:53: 38172
>> sqrt 2019-04-10 23:53:54: 131081408
>> sqrt 2019-04-10 23:53:55: 43600
>> sqrt 2019-04-10 23:53:56: 46704
>> sqrt 2019-04-10 23:53:57: 46880
>> sqrt 2019-04-10 23:53:58: 44332
>> ……
>> sqrt 2019-04-10 02:17:15: 131081408
>> ……
>> sqrt 2019-04-10 04:40:35: 131081408
>> ……
>>
>> Every 2hour23min there would be a large cycles. I use perf sched not found 
>> any sched_switch events.
> 
> Hi,
> 
> The fact that it is the same value 131081408 every 2 hours 23 minutes looks 
> suspect. One would expect some variation in the counts.  It looks like there 
> is some rollover or overflow issue.  It would be helpful to print out the 
> start and end values to see what is going on with the raw rdstc values.  
> Maybe the thread is being moved between processors and the TSC are out of 
> sync.  What particular processor model was this running on? Was this running 
> on physical hardware or inside a kvm guest? 
> 
> According to the Intel 64 and IA-32 Architecture Software Devloper's Manual 
> Volume 3 (325384-sdm-vol-3abcd.pdf):
> 
> The RDTSC instruction reads the time-stamp counter and is guaranteed to 
> return a monotonically increasing unique value whenever executed, except for 
> a 64-bit counter wraparound. Intel guarantees that the time-stamp counter 
> will not wraparound within 10 years after being reset. The period for counter 
> wrap is longer for Pentium 4, Intel Xeon, P6 family, and Pentium processors.
> 
> -Will Cohen
> 
> 
>>
>> L2GW_2680:/home/fsp/zn # perf sched record -C 6-11 -o perf.sched ^C[ 
>> perf record: Woken up 64 times to write data ] [ perf record: Captured 
>> and wrote 204.878 MB perf.sched (1911189 samples) ]
>>
>> L2GW_2680:/home/fsp/zn # perf sched latency -i perf.sched
>>
>> --
>> ---
>>   Task  |   Runtime ms  | Switches | Average delay ms 
>> | Maximum delay ms | Maximum delay at   |
>> --
>> ---
>> --
>> ---
>>   TOTAL:    |  0.000 ms |    0 |
>> ---
>>
>>
>>
>> Is there any other tools of perf to found out the max latency by irq or cpu 
>> idle ?
>>
>>
>

[tip:perf/core] perf vendor events power9: General metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  33937e599449c65dbd69c60d7e2255012427baed
Gitweb: https://git.kernel.org/tip/33937e599449c65dbd69c60d7e2255012427baed
Author: Paul Clarke 
AuthorDate: Sat, 9 Feb 2019 13:14:29 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:11 -0300

perf vendor events power9: General metrics

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- general

and other metrics not in a metric group.

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Cc: linuxppc-...@ozlabs.org
Link: http://lkml.kernel.org/r/20190209181429.23950-5...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power9/metrics.json| 368 +
 1 file changed, 368 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index c39a922aaf84..811c2a8c1c9e 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -813,6 +813,114 @@
 "MetricGroup": "estimated_dcache_miss_cpi",
 "MetricName": "rmem_cpi_percent"
 },
+{
+"BriefDescription": "Branch Mispredict flushes per instruction",
+"MetricExpr": "PM_FLUSH_MPRED / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "general",
+"MetricName": "br_mpred_flush_rate_percent"
+},
+{
+"BriefDescription": "Cycles per instruction",
+"MetricExpr": "PM_CYC / PM_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "cpi"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "(PM_FLUSH_DISP / PM_RUN_INST_CMPL) * 100",
+"MetricGroup": "general",
+"MetricName": "disp_flush_rate_percent"
+},
+{
+"BriefDescription": "% DTLB miss rate per inst",
+"MetricExpr": "PM_DTLB_MISS / PM_RUN_INST_CMPL *100",
+"MetricGroup": "general",
+"MetricName": "dtlb_miss_rate_percent"
+},
+{
+"BriefDescription": "Flush rate (%)",
+"MetricExpr": "PM_FLUSH * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "flush_rate_percent"
+},
+{
+"BriefDescription": "Instructions per cycles",
+"MetricExpr": "PM_INST_CMPL / PM_CYC",
+"MetricGroup": "general",
+"MetricName": "ipc"
+},
+{
+"BriefDescription": "% ITLB miss rate per inst",
+"MetricExpr": "PM_ITLB_MISS / PM_RUN_INST_CMPL *100",
+"MetricGroup": "general",
+"MetricName": "itlb_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L1 load misses per L1 load ref",
+"MetricExpr": "PM_LD_MISS_L1 / PM_LD_REF_L1 * 100",
+"MetricGroup": "general",
+"MetricName": "l1_ld_miss_ratio_percent"
+},
+{
+"BriefDescription": "Percentage of L1 store misses per run 
instruction",
+"MetricExpr": "PM_ST_MISS_L1 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l1_st_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L1 store misses per L1 store ref",
+"MetricExpr": "PM_ST_MISS_L1 / PM_ST_FIN * 100",
+"MetricGroup": "general",
+"MetricName": "l1_st_miss_ratio_percent"
+},
+{
+"BriefDescription": "L2 Instruction Miss Rate (per instruction)(%)",
+"MetricExpr": "PM_INST_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l2_inst_miss_rate_percent"
+},
+

[tip:perf/core] perf vendor events power9: Branch_prediction, instruction_stats, latency, lsu_rejects, memory, prefetch & translation metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  a4d832726471963b327fae33f14fa28c83db6a0e
Gitweb: https://git.kernel.org/tip/a4d832726471963b327fae33f14fa28c83db6a0e
Author: Paul Clarke 
AuthorDate: Sat, 9 Feb 2019 13:14:28 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:10 -0300

perf vendor events power9: Branch_prediction, instruction_stats, latency, 
lsu_rejects, memory, prefetch & translation metrics

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- branch_prediction
- instruction_stats_percent_per_ref
- latency
- lsu_rejects
- memory
- prefetch
- translation

Plus, some whitespace changes.

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Cc: linuxppc-...@ozlabs.org
Link: http://lkml.kernel.org/r/20190209181429.23950-4...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power9/metrics.json| 403 -
 1 file changed, 390 insertions(+), 13 deletions(-)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index 166f95518c45..c39a922aaf84 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -1,4 +1,39 @@
 [
+{
+"MetricExpr": "PM_BR_MPRED_CMPL / PM_BR_PRED * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "br_misprediction_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction per instruction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_BR_PRED_CCACHE * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_misprediction_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "PM_BR_MPRED_LSTACK / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "PM_BR_MPRED_LSTACK/ PM_BR_PRED_LSTACK * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_misprediction_percent"
+},
+{
+"BriefDescription": "% Branches Taken",
+"MetricExpr": "PM_BR_TAKEN_CMPL * 100 / PM_BRU_FIN",
+"MetricGroup": "branch_prediction",
+"MetricName": "taken_branches_percent"
+},
 {
 "BriefDescription": "Completion stall due to a Branch Unit",
 "MetricExpr": "PM_CMPLU_STALL_BRU/PM_RUN_INST_CMPL",
@@ -881,13 +916,121 @@
 "MetricName": "l1_inst_miss_rate_percent"
 },
 {
-"BriefDescription": "%L2 Modified CO  Cache read Utilization (4 pclks 
per disp attempt)",
+"BriefDescription": "Icache Fetchs per Icache Miss",
+"MetricExpr": "(PM_L1_ICACHE_MISS - PM_IC_PREF_WRITE) / 
PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "icache_miss_reload"
+},
+{
+"BriefDescription": "% of ICache reloads due to prefetch",
+"MetricExpr": "PM_IC_PREF_WRITE * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "icache_pref_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Distant L2 or L3 
(Modified)",
+"MetricExpr": "PM_INST_FROM_DL2L3_MOD * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName":

[tip:perf/core] perf vendor events power9: Dl1_reloads, instruction_misses, l[23]_stats & pteg_reloads metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  0133491d4641b493aa0d0e5bd66b52999619cd8a
Gitweb: https://git.kernel.org/tip/0133491d4641b493aa0d0e5bd66b52999619cd8a
Author: Paul Clarke 
AuthorDate: Sat, 9 Feb 2019 13:14:27 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:10 -0300

perf vendor events power9: Dl1_reloads, instruction_misses, l[23]_stats & 
pteg_reloads metrics

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- dl1_reloads_percent_per_inst
- dl1_reloads_percent_per_ref
- instruction_misses_percent_per_inst
- l2_stats
- l3_stats
- pteg_reloads_percent_per_inst
- pteg_reloads_percent_per_ref

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Cc: linuxppc-...@ozlabs.org
Link: http://lkml.kernel.org/r/20190209181429.23950-3...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power9/metrics.json| 660 +
 1 file changed, 660 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index cd46ebb8da6a..166f95518c45 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -484,6 +484,210 @@
 "MetricGroup": "cpi_breakdown",
 "MetricName": "vfxu_stall_cpi"
 },
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Modified) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Shared) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant Memory per Inst",
+"MetricExpr": "PM_DATA_FROM_DMEM * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dmem_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_miss_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3 M state, other 
core per Inst",
+"MetricExpr": "PM_DATA_FROM_L31_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l31_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3 S tate, other 
core per Inst",
+"MetricExpr": "PM_DATA_FROM_L31_SHR * 100 / PM_RUN_INST_C

[tip:perf/core] perf vendor events power8: Translaton & general metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  72ab50203f3f588c2b64c68f11a28ef56a8ff1a1
Gitweb: https://git.kernel.org/tip/72ab50203f3f588c2b64c68f11a28ef56a8ff1a1
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:14 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:10 -0300

perf vendor events power8: Translaton & general metrics

POWER8 metrics are not well publicized.

Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- translation
- general

and other metrics not in a metric group.

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-5...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 590 +
 1 file changed, 590 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index d8b710e12377..bffb2d4a6420 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -836,6 +836,216 @@
 "MetricGroup": "estimated_dcache_miss_cpi",
 "MetricName": "rmem_cpi_percent"
 },
+{
+"BriefDescription": "Branch Mispredict flushes per instruction",
+"MetricExpr": "PM_FLUSH_BR_MPRED / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "general",
+"MetricName": "br_mpred_flush_rate_percent"
+},
+{
+"BriefDescription": "Cycles per instruction",
+"MetricExpr": "PM_CYC / PM_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "cpi"
+},
+{
+"BriefDescription": "Percentage Cycles a group completed",
+"MetricExpr": "PM_GRP_CMPL / PM_CYC * 100",
+"MetricGroup": "general",
+"MetricName": "cyc_grp_completed_percent"
+},
+{
+"BriefDescription": "Percentage Cycles a group dispatched",
+"MetricExpr": "PM_1PLUS_PPC_DISP / PM_CYC * 100",
+"MetricGroup": "general",
+"MetricName": "cyc_grp_dispatched_percent"
+},
+{
+"BriefDescription": "Cycles per group",
+"MetricExpr": "PM_CYC / PM_1PLUS_PPC_CMPL",
+"MetricGroup": "general",
+"MetricName": "cyc_per_group"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "(PM_FLUSH_DISP / PM_RUN_INST_CMPL) * 100",
+"MetricGroup": "general",
+"MetricName": "disp_flush_rate_percent"
+},
+{
+"BriefDescription": "% DTLB miss rate per inst",
+"MetricExpr": "PM_DTLB_MISS  / PM_RUN_INST_CMPL *100",
+"MetricGroup": "general",
+"MetricName": "dtlb_miss_rate_percent"
+},
+{
+"BriefDescription": "Flush rate (%)",
+"MetricExpr": "PM_FLUSH * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "flush_rate_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (11 to 14) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_11_14_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_11to14_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (15 to 17) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_15_17_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_15to17_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization 18+ as a % of cycles this 
thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_18_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_18plus_slots

[tip:perf/core] perf vendor events power9: Cpi_breakdown & estimated_dcache_miss_cpi metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  7f3cf5ac7743f924753a2c75fd71317e418844d0
Gitweb: https://git.kernel.org/tip/7f3cf5ac7743f924753a2c75fd71317e418844d0
Author: Paul Clarke 
AuthorDate: Sat, 9 Feb 2019 13:14:26 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:10 -0300

perf vendor events power9: Cpi_breakdown & estimated_dcache_miss_cpi metrics

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- cpi_breakdown
- estimated_dcache_miss_cpi

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Cc: linuxppc-...@ozlabs.org
Link: http://lkml.kernel.org/r/20190209181429.23950-2...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power9/metrics.json| 577 +
 1 file changed, 577 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
new file mode 100644
index ..cd46ebb8da6a
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -0,0 +1,577 @@
+[
+{
+"BriefDescription": "Completion stall due to a Branch Unit",
+"MetricExpr": "PM_CMPLU_STALL_BRU/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was 
routed to the crypto execution pipe and was waiting to finish",
+"MetricExpr": "PM_CMPLU_STALL_CRYPTO/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "crypto_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was a 
load that missed the L1 and was waiting for the data to return from the nest",
+"MetricExpr": "PM_CMPLU_STALL_DCACHE_MISS/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dcache_miss_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was a 
multi-cycle instruction issued to the Decimal Floating Point execution pipe and 
waiting to finish.",
+"MetricExpr": "PM_CMPLU_STALL_DFLONG/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dflong_stall_cpi"
+},
+{
+"BriefDescription": "Stalls due to short latency decimal floating 
ops.",
+"MetricExpr": "(PM_CMPLU_STALL_DFU - 
PM_CMPLU_STALL_DFLONG)/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dfu_other_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was 
issued to the Decimal Floating Point execution pipe and waiting to finish.",
+"MetricExpr": "PM_CMPLU_STALL_DFU/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dfu_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall by Dcache miss which resolved 
off node memory/cache",
+"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS - 
PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM - 
PM_CMPLU_STALL_DMISS_REMOTE)/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_distant_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall by Dcache miss which resolved on 
chip ( excluding local L2/L3)",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_L21_L31/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l21_l31_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall due to cache miss that resolves 
in the L2 or L3 with a conflict",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_L2L3_CONFLICT/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l2l3_conflict_stall_cpi"
+},
+

[tip:perf/core] perf vendor events power8: Branch_prediction, latency, bus_stats, instruction_mix & instruction_stats metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  69ba708f4df6250dfa0410297024eeedd7ab3362
Gitweb: https://git.kernel.org/tip/69ba708f4df6250dfa0410297024eeedd7ab3362
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:13 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:09 -0300

perf vendor events power8: Branch_prediction, latency, bus_stats, 
instruction_mix & instruction_stats metrics

POWER8 metrics are not well publicized.  Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- branch_prediction
- latency
- bus_stats
- instruction_mix
- instruction_stats_percent_per_ref

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-4...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 492 +
 1 file changed, 492 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index 9a6ec8aadffd..d8b710e12377 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -1,4 +1,100 @@
 [
+{
+"BriefDescription": "% of finished branches that were treated as BC+8",
+"MetricExpr": "PM_BR_BC_8_CONV / PM_BRU_FIN * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "bc_8_branch_ratio_percent"
+},
+{
+"BriefDescription": "% of finished branches that were pairable but not 
treated as BC+8",
+"MetricExpr": "PM_BR_BC_8 / PM_BRU_FIN * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "bc_8_not_converted_branch_ratio_percent"
+},
+{
+"BriefDescription": "Percent of mispredicted branches out of all 
predicted (correctly and incorrectly) branches that completed",
+"MetricExpr": "PM_BR_MPRED_CMPL / (PM_BR_PRED_BR0 + PM_BR_PRED_BR1) * 
100",
+"MetricGroup": "branch_prediction",
+"MetricName": "br_misprediction_percent"
+},
+{
+"BriefDescription": "% of Branch miss predictions per instruction",
+"MetricExpr": "PM_BR_MPRED_CMPL / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "branch_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction per instruction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of count catch mispredictions out of all 
completed branches that required count cache predictionn",
+"MetricExpr": "PM_BR_MPRED_CCACHE / (PM_BR_PRED_CCACHE_BR0 + 
PM_BR_PRED_CCACHE_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_misprediction_percent"
+},
+{
+"BriefDescription": "CR MisPredictions per Instruction",
+"MetricExpr": "PM_BR_MPRED_CR / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "cr_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "(PM_BR_MPRED_TA - PM_BR_MPRED_CCACHE) / 
PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of link stack mispredictions out of all 
completed branches that required link stack prediction",
+"MetricExpr": "(PM_BR_MPRED_TA - PM_BR_MPRED_CCACHE) / 
(PM_BR_PRED_LSTACK_BR0 + PM_BR_PRED_LSTACK_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_misprediction_percent"
+},
+{
+"BriefDescription": "TA MisPredictions per Instruction",
+"MetricExpr": "PM_BR_MPRED_TA / PM_RUN_INST_CMPL * 100",
+"MetricGroup":

[tip:perf/core] perf vendor events power8: Dl1_reload, instruction_misses, l2_stats, lsu_rejects, memory & pteg_reloads metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  ffe18505ba1d641a4935321d3c525e4e2efd64c3
Gitweb: https://git.kernel.org/tip/ffe18505ba1d641a4935321d3c525e4e2efd64c3
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:12 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:09 -0300

perf vendor events power8: Dl1_reload, instruction_misses, l2_stats, 
lsu_rejects, memory & pteg_reloads metrics

POWER8 metrics are not well publicized.

Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- dl1_reloads_percent_per_inst
- dl1_reloads_percent_per_ref
- instruction_misses_percent_per_inst
- l2_stats
- lsu_rejects
- memory
- pteg_reloads_percent_per_inst
- pteg_reloads_percent_per_ref

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-3...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 702 +
 1 file changed, 702 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index 377b76226c08..9a6ec8aadffd 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -356,6 +356,288 @@
 "MetricGroup": "cpi_breakdown",
 "MetricName": "vsu_stall_vector_other_cpi"
 },
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Modified) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Shared) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L4 per Inst",
+"MetricExpr": "PM_DATA_FROM_DL4 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl4_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant Memory per Inst",
+"MetricExpr": "PM_DATA_FROM_DMEM * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dmem_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_shr_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 experienced a Load-Hit-Store conflict",
+"MetricExpr": "PM_DATA_FROM_L2_DISP_CONFLICT_LDHITST * 100 / 
PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_lhs_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 did not experience a conflict",
+"MetricExpr": "PM_DATA_FROM_L2_NO_CONFLICT * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+&q

[tip:perf/core] perf vendor events power8: Cpi_breakdown & estimated_dcache_miss_cpi metrics

2019-02-15 Thread tip-bot for Paul Clarke

Commit-ID:  dd81eafacc52961ed1b2bf3e998b92ccfd9108bc
Gitweb: https://git.kernel.org/tip/dd81eafacc52961ed1b2bf3e998b92ccfd9108bc
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:11 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:08 -0300

perf vendor events power8: Cpi_breakdown & estimated_dcache_miss_cpi metrics

POWER8 metrics are not well publicized.

Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- cpi_breakdown
- estimated_dcache_miss_cpi

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-2...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 461 +
 1 file changed, 461 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
new file mode 100644
index ..377b76226c08
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -0,0 +1,461 @@
+[
+{
+"BriefDescription": "Cycles stalled due to CRU or BRU operations",
+"MetricExpr": "PM_CMPLU_STALL_BRU_CRU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_cru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled due to ISU Branch Operations",
+"MetricExpr": "PM_CMPLU_STALL_BRU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles in which a Group Completed",
+"MetricExpr": "PM_GRP_CMPL / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "completion_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by CO queue full",
+"MetricExpr": "PM_CMPLU_STALL_COQ_FULL / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "coq_full_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled due to CRU Operations",
+"MetricExpr": "(PM_CMPLU_STALL_BRU_CRU - PM_CMPLU_STALL_BRU) / 
PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "cru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by flushes",
+"MetricExpr": "PM_CMPLU_STALL_FLUSH / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "flush_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by FXU Multi-Cycle Instructions",
+"MetricExpr": "PM_CMPLU_STALL_FXLONG / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_multi_cyc_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by FXU",
+"MetricExpr": "PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_stall_cpi"
+},
+{
+"BriefDescription": "Other cycles stalled by FXU",
+"MetricExpr": "(PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL) - 
(PM_CMPLU_STALL_FXLONG / PM_RUN_INST_CMPL)",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_stall_other_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty due to Branch Mispredicts",
+"MetricExpr": "PM_GCT_NOSLOT_BR_MPRED / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_br_mpred_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty due to Branch Mispredicts and 
Icache Misses",
+"MetricExpr": "PM_GCT_NOSLOT_BR_MPRED_ICMISS / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_br_mpred_ic_miss_cpi"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "PM_GCT_NOSLOT_CYC / P

[PATCH 2/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

2019-02-09 Thread Paul Clarke

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- dl1_reloads_percent_per_inst
- dl1_reloads_percent_per_ref
- instruction_misses_percent_per_inst
- l2_stats
- l3_stats
- pteg_reloads_percent_per_inst
- pteg_reloads_percent_per_ref

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power9/metrics.json  | 660 ++
 1 file changed, 660 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index cd46ebb8da6a..166f95518c45 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -484,6 +484,210 @@
 "MetricGroup": "cpi_breakdown",
 "MetricName": "vfxu_stall_cpi"
 },
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Modified) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Shared) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant Memory per Inst",
+"MetricExpr": "PM_DATA_FROM_DMEM * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dmem_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_miss_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3 M state, other 
core per Inst",
+"MetricExpr": "PM_DATA_FROM_L31_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l31_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3 S tate, other 
core per Inst",
+"MetricExpr": "PM_DATA_FROM_L31_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l31_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads that came from the L3 and were 
brought into the L3 by a prefetch, per instruction completed",
+"MetricExpr": "PM_DATA_FROM_L3_MEPF * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l3_mepf_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L3 per Inst",
+"MetricExpr": "PM_DATA_FROM_L3MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l3_miss_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from L3 per Inst",
+"MetricExpr": "PM_DATA_FROM_L3 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l3_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Local Memory per Inst",
+"MetricExpr": "PM_DATA_FROM_LMEM * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_lmem_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_RL2L3_MOD *

[PATCH 1/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

2019-02-09 Thread Paul Clarke

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- cpi_breakdown
- estimated_dcache_miss_cpi

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power9/metrics.json  | 577 ++
 1 file changed, 577 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/powerpc/power9/metrics.json

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
new file mode 100644
index ..cd46ebb8da6a
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -0,0 +1,577 @@
+[
+{
+"BriefDescription": "Completion stall due to a Branch Unit",
+"MetricExpr": "PM_CMPLU_STALL_BRU/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was 
routed to the crypto execution pipe and was waiting to finish",
+"MetricExpr": "PM_CMPLU_STALL_CRYPTO/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "crypto_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was a 
load that missed the L1 and was waiting for the data to return from the nest",
+"MetricExpr": "PM_CMPLU_STALL_DCACHE_MISS/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dcache_miss_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was a 
multi-cycle instruction issued to the Decimal Floating Point execution pipe and 
waiting to finish.",
+"MetricExpr": "PM_CMPLU_STALL_DFLONG/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dflong_stall_cpi"
+},
+{
+"BriefDescription": "Stalls due to short latency decimal floating 
ops.",
+"MetricExpr": "(PM_CMPLU_STALL_DFU - 
PM_CMPLU_STALL_DFLONG)/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dfu_other_stall_cpi"
+},
+{
+"BriefDescription": "Finish stall because the NTF instruction was 
issued to the Decimal Floating Point execution pipe and waiting to finish.",
+"MetricExpr": "PM_CMPLU_STALL_DFU/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dfu_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall by Dcache miss which resolved 
off node memory/cache",
+"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS - 
PM_CMPLU_STALL_DMISS_L21_L31 - PM_CMPLU_STALL_DMISS_LMEM - 
PM_CMPLU_STALL_DMISS_REMOTE)/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_distant_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall by Dcache miss which resolved on 
chip ( excluding local L2/L3)",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_L21_L31/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l21_l31_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall due to cache miss that resolves 
in the L2 or L3 with a conflict",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_L2L3_CONFLICT/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l2l3_conflict_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall due to cache miss that resolves 
in the L2 or L3 without conflict",
+"MetricExpr": "(PM_CMPLU_STALL_DMISS_L2L3 - 
PM_CMPLU_STALL_DMISS_L2L3_CONFLICT)/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l2l3_noconflict_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall by Dcache miss which resolved in 
L2/L3",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_L2L3/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l2l3_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall due to cache miss resolving 
missed the L3",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_L3MISS/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_l3miss_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall due to cache miss that resolves 
in local memory",
+"MetricExpr": "PM_CMPLU_STALL_DMISS_LMEM/PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "dmiss_lmem_stall_cpi"
+},
+{
+"BriefDescription": "Completion stall by Dcache miss which resolved 
outside of local memory",
+"MetricExpr": "(PM_CMPLU_STALL_DMISS_L3MISS -

[PATCH v2 0/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

2019-02-09 Thread Paul Clarke

[Note this is for POWER*9* and is different content than a
previous patchset for POWER*8*.]

The patches define metrics and metric groups for computation by "perf"
for POWER9 processors.

Paul Clarke (4):
  [powerpc] perf vendor events: Add JSON metrics for POWER9
  [powerpc] perf vendor events: Add JSON metrics for POWER9
  [powerpc] perf vendor events: Add JSON metrics for POWER9
  [powerpc] perf vendor events: Add JSON metrics for POWER9

v2:
The content of these patches was sent previously, to LKML and
linux-perf-users, but never showed up at linux-perf-users, so
I split it into smaller patches and am resending.

 .../arch/powerpc/power9/metrics.json  | 1982 +
 1 file changed, 1982 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/powerpc/power9/metrics.json

-- 
2.17.1

[PATCH 4/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

2019-02-09 Thread Paul Clarke

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- general

and other metrics not in a metric group.

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power9/metrics.json  | 368 ++
 1 file changed, 368 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index c39a922aaf84..811c2a8c1c9e 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -813,6 +813,114 @@
 "MetricGroup": "estimated_dcache_miss_cpi",
 "MetricName": "rmem_cpi_percent"
 },
+{
+"BriefDescription": "Branch Mispredict flushes per instruction",
+"MetricExpr": "PM_FLUSH_MPRED / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "general",
+"MetricName": "br_mpred_flush_rate_percent"
+},
+{
+"BriefDescription": "Cycles per instruction",
+"MetricExpr": "PM_CYC / PM_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "cpi"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "(PM_FLUSH_DISP / PM_RUN_INST_CMPL) * 100",
+"MetricGroup": "general",
+"MetricName": "disp_flush_rate_percent"
+},
+{
+"BriefDescription": "% DTLB miss rate per inst",
+"MetricExpr": "PM_DTLB_MISS / PM_RUN_INST_CMPL *100",
+"MetricGroup": "general",
+"MetricName": "dtlb_miss_rate_percent"
+},
+{
+"BriefDescription": "Flush rate (%)",
+"MetricExpr": "PM_FLUSH * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "flush_rate_percent"
+},
+{
+"BriefDescription": "Instructions per cycles",
+"MetricExpr": "PM_INST_CMPL / PM_CYC",
+"MetricGroup": "general",
+"MetricName": "ipc"
+},
+{
+"BriefDescription": "% ITLB miss rate per inst",
+"MetricExpr": "PM_ITLB_MISS / PM_RUN_INST_CMPL *100",
+"MetricGroup": "general",
+"MetricName": "itlb_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L1 load misses per L1 load ref",
+"MetricExpr": "PM_LD_MISS_L1 / PM_LD_REF_L1 * 100",
+"MetricGroup": "general",
+"MetricName": "l1_ld_miss_ratio_percent"
+},
+{
+"BriefDescription": "Percentage of L1 store misses per run 
instruction",
+"MetricExpr": "PM_ST_MISS_L1 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l1_st_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L1 store misses per L1 store ref",
+"MetricExpr": "PM_ST_MISS_L1 / PM_ST_FIN * 100",
+"MetricGroup": "general",
+"MetricName": "l1_st_miss_ratio_percent"
+},
+{
+"BriefDescription": "L2 Instruction Miss Rate (per instruction)(%)",
+"MetricExpr": "PM_INST_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l2_inst_miss_rate_percent"
+},
+{
+"BriefDescription": "L2 dmand Load Miss Rate (per run instruction)(%)",
+"MetricExpr": "PM_DATA_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l2_ld_miss_rate_percent"
+},
+{
+"BriefDescription": "L2 PTEG Miss Rate (per run instruction)(%)",
+"MetricExpr": "PM_DPTEG_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l2_pteg_miss_rate_percent"
+},
+{
+"BriefDescription": "L3 Instruction Miss Rate (per instruction)(%)",
+"MetricExpr": "PM_INST_FROM_L3MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l3_inst_miss_rate_percent"
+},
+{
+"BriefDescription": "L3 demand Load Miss Rate (per run 
instruction)(%)",
+"MetricExpr": "PM_DATA_FROM_L3MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l3_ld_miss_rate_percent"
+},
+{
+"BriefDescription": "L3 PTEG Miss Rate (per run instruction)(%)",
+"MetricExpr": "PM_DPTEG_FROM_L3MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "l3_pteg_miss_rate_percent"
+},
+{
+"BriefDescription": "Run cycles per cycle",
+"MetricExpr": "PM_RUN_CYC / PM_CYC*100",
+"MetricGroup": "general",
+"MetricName": "run_cycles_percent"
+},
+{
+"BriefDescription": "Instruction dispatch-to-completion ratio",
+"MetricExpr": "PM_INST_DISP /

[PATCH 3/4] [powerpc] perf vendor events: Add JSON metrics for POWER9

2019-02-09 Thread Paul Clarke

Descriptions of metrics for POWER9 processors can be found in the
"POWER9 Performance Monitor Unit User’s Guide", which is currently
available on the "IBM Portal for OpenPOWER"
(https://www-355.ibm.com/systems/power/openpower/welcome.xhtml) at
https://www-355.ibm.com/systems/power/openpower/posting.xhtml?postingId=4948CDE1963C9BCA852582F800718190

This patch is for metric groups:
- branch_prediction
- instruction_stats_percent_per_ref
- latency
- lsu_rejects
- memory
- prefetch
- translation

Plus, some whitespace changes.

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power9/metrics.json  | 403 +-
 1 file changed, 390 insertions(+), 13 deletions(-)

diff --git a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
index 166f95518c45..c39a922aaf84 100644
--- a/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power9/metrics.json
@@ -1,4 +1,39 @@
 [
+{
+"MetricExpr": "PM_BR_MPRED_CMPL / PM_BR_PRED * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "br_misprediction_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction per instruction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_BR_PRED_CCACHE * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_misprediction_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "PM_BR_MPRED_LSTACK / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "PM_BR_MPRED_LSTACK/ PM_BR_PRED_LSTACK * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_misprediction_percent"
+},
+{
+"BriefDescription": "% Branches Taken",
+"MetricExpr": "PM_BR_TAKEN_CMPL * 100 / PM_BRU_FIN",
+"MetricGroup": "branch_prediction",
+"MetricName": "taken_branches_percent"
+},
 {
 "BriefDescription": "Completion stall due to a Branch Unit",
 "MetricExpr": "PM_CMPLU_STALL_BRU/PM_RUN_INST_CMPL",
@@ -881,13 +916,121 @@
 "MetricName": "l1_inst_miss_rate_percent"
 },
 {
-"BriefDescription": "%L2 Modified CO  Cache read Utilization (4 pclks 
per disp attempt)",
+"BriefDescription": "Icache Fetchs per Icache Miss",
+"MetricExpr": "(PM_L1_ICACHE_MISS - PM_IC_PREF_WRITE) / 
PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "icache_miss_reload"
+},
+{
+"BriefDescription": "% of ICache reloads due to prefetch",
+"MetricExpr": "PM_IC_PREF_WRITE * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "icache_pref_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Distant L2 or L3 
(Modified)",
+"MetricExpr": "PM_INST_FROM_DL2L3_MOD * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "inst_from_dl2l3_mod_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Distant L2 or L3 
(Shared)",
+"MetricExpr": "PM_INST_FROM_DL2L3_SHR * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "inst_from_dl2l3_shr_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Distant L4",
+"MetricExpr": "PM_INST_FROM_DL4 * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "inst_from_dl4_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Distant Memory",
+"MetricExpr": "PM_INST_FROM_DMEM * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "inst_from_dmem_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Private L2, other core",
+"MetricExpr": "PM_INST_FROM_L21_MOD * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "inst_from_l21_mod_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from Private L2, other core",
+"MetricExpr": "PM_INST_FROM_L21_SHR * 100 / PM_L1_ICACHE_MISS",
+"MetricGroup": "instruction_stats_percent_per_ref",
+"MetricName": "inst_from_l21_shr_percent"
+},
+{
+"BriefDescription": "% of ICache reloads from L2",
+

[PATCH v2 2/4] [powerpc] perf vendor events: Add JSON metrics for POWER8

2019-02-07 Thread Paul Clarke

POWER8 metrics not well publicized.  Some are here:
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- dl1_reloads_percent_per_inst
- dl1_reloads_percent_per_ref
- instruction_misses_percent_per_inst
- l2_stats
- lsu_rejects
- memory
- pteg_reloads_percent_per_inst
- pteg_reloads_percent_per_ref

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power8/metrics.json  | 702 ++
 1 file changed, 702 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index 377b76226c08..9a6ec8aadffd 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -356,6 +356,288 @@
 "MetricGroup": "cpi_breakdown",
 "MetricName": "vsu_stall_vector_other_cpi"
 },
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Modified) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Shared) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L4 per Inst",
+"MetricExpr": "PM_DATA_FROM_DL4 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl4_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant Memory per Inst",
+"MetricExpr": "PM_DATA_FROM_DMEM * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dmem_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_shr_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 experienced a Load-Hit-Store conflict",
+"MetricExpr": "PM_DATA_FROM_L2_DISP_CONFLICT_LDHITST * 100 / 
PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_lhs_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 did not experience a conflict",
+"MetricExpr": "PM_DATA_FROM_L2_NO_CONFLICT * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_no_conflict_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 experienced some conflict other than Load-Hit-Store",
+"MetricExpr": "PM_DATA_FROM_L2_DISP_CONFLICT_OTHER * 100 / 
PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_other_conflict_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3 M state, other 
core per Inst",
+"MetricExpr": "PM_DATA_FROM_L31_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l31_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L3 S tate, other 
core per Inst",
+"MetricExpr": "PM_DATA_FROM_L31_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l31_shr_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L3 load hits per instruction where 
the load collided with

[PATCH v2 3/4] [powerpc] perf vendor events: Add JSON metrics for POWER8

2019-02-07 Thread Paul Clarke

POWER8 metrics not well publicized.  Some are here:
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- branch_prediction
- latency
- bus_stats
- instruction_mix
- instruction_stats_percent_per_ref

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power8/metrics.json  | 492 ++
 1 file changed, 492 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index 9a6ec8aadffd..d8b710e12377 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -1,4 +1,100 @@
 [
+{
+"BriefDescription": "% of finished branches that were treated as BC+8",
+"MetricExpr": "PM_BR_BC_8_CONV / PM_BRU_FIN * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "bc_8_branch_ratio_percent"
+},
+{
+"BriefDescription": "% of finished branches that were pairable but not 
treated as BC+8",
+"MetricExpr": "PM_BR_BC_8 / PM_BRU_FIN * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "bc_8_not_converted_branch_ratio_percent"
+},
+{
+"BriefDescription": "Percent of mispredicted branches out of all 
predicted (correctly and incorrectly) branches that completed",
+"MetricExpr": "PM_BR_MPRED_CMPL / (PM_BR_PRED_BR0 + PM_BR_PRED_BR1) * 
100",
+"MetricGroup": "branch_prediction",
+"MetricName": "br_misprediction_percent"
+},
+{
+"BriefDescription": "% of Branch miss predictions per instruction",
+"MetricExpr": "PM_BR_MPRED_CMPL / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "branch_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction per instruction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of count catch mispredictions out of all 
completed branches that required count cache predictionn",
+"MetricExpr": "PM_BR_MPRED_CCACHE / (PM_BR_PRED_CCACHE_BR0 + 
PM_BR_PRED_CCACHE_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_misprediction_percent"
+},
+{
+"BriefDescription": "CR MisPredictions per Instruction",
+"MetricExpr": "PM_BR_MPRED_CR / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "cr_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "(PM_BR_MPRED_TA - PM_BR_MPRED_CCACHE) / 
PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of link stack mispredictions out of all 
completed branches that required link stack prediction",
+"MetricExpr": "(PM_BR_MPRED_TA - PM_BR_MPRED_CCACHE) / 
(PM_BR_PRED_LSTACK_BR0 + PM_BR_PRED_LSTACK_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_misprediction_percent"
+},
+{
+"BriefDescription": "TA MisPredictions per Instruction",
+"MetricExpr": "PM_BR_MPRED_TA / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ta_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of target address mispredictions out of 
all completed branches that required address prediction",
+"MetricExpr": "PM_BR_MPRED_TA / (PM_BR_PRED_CCACHE_BR0 + 
PM_BR_PRED_CCACHE_BR1 + PM_BR_PRED_LSTACK_BR0 + PM_BR_PRED_LSTACK_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ta_misprediction_percent"
+},
+{
+"BriefDescription": "Percent of branches completed that were taken",
+"MetricExpr": "PM_BR_TAKEN_CMPL * 100 / PM_BR_CMPL",
+"MetricGroup": "branch_prediction",
+"MetricName": "taken_branches_percent"
+},
+{
+"BriefDescription": "Percent of chip+group+sys pumps that were 
incorrectly predicted",
+"MetricExpr": "PM_PUMP_MPRED * 100 / (PM_PUMP_CPRED + PM_PUMP_MPRED)",
+"MetricGroup": "bus_stats",
+"MetricName": "any_pump_mpred_percent"
+},
+{
+"BriefDescription": "Percent of chip pumps that were correctly 
predicted as chip pumps the first time",
+"MetricExpr": "PM_CHIP_PUMP_CPRED * 100 / PM_L2_CHIP_PUMP",
+"MetricGroup": "bus_stats",
+"MetricName": "chip_pump_cpred_percent"
+},
+{
+"BriefDescription": "Percent of group pumps that were correctly 
predicted as group pumps the first time",
+"MetricExpr":

[PATCH v2 4/4] [powerpc] perf vendor events: Add JSON metrics for POWER8

2019-02-07 Thread Paul Clarke

POWER8 metrics not well publicized.  Some are here:
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- translation
- general

and other metrics not in a metric group.

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power8/metrics.json  | 590 ++
 1 file changed, 590 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index d8b710e12377..bffb2d4a6420 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -836,6 +836,216 @@
 "MetricGroup": "estimated_dcache_miss_cpi",
 "MetricName": "rmem_cpi_percent"
 },
+{
+"BriefDescription": "Branch Mispredict flushes per instruction",
+"MetricExpr": "PM_FLUSH_BR_MPRED / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "general",
+"MetricName": "br_mpred_flush_rate_percent"
+},
+{
+"BriefDescription": "Cycles per instruction",
+"MetricExpr": "PM_CYC / PM_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "cpi"
+},
+{
+"BriefDescription": "Percentage Cycles a group completed",
+"MetricExpr": "PM_GRP_CMPL / PM_CYC * 100",
+"MetricGroup": "general",
+"MetricName": "cyc_grp_completed_percent"
+},
+{
+"BriefDescription": "Percentage Cycles a group dispatched",
+"MetricExpr": "PM_1PLUS_PPC_DISP / PM_CYC * 100",
+"MetricGroup": "general",
+"MetricName": "cyc_grp_dispatched_percent"
+},
+{
+"BriefDescription": "Cycles per group",
+"MetricExpr": "PM_CYC / PM_1PLUS_PPC_CMPL",
+"MetricGroup": "general",
+"MetricName": "cyc_per_group"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "(PM_FLUSH_DISP / PM_RUN_INST_CMPL) * 100",
+"MetricGroup": "general",
+"MetricName": "disp_flush_rate_percent"
+},
+{
+"BriefDescription": "% DTLB miss rate per inst",
+"MetricExpr": "PM_DTLB_MISS  / PM_RUN_INST_CMPL *100",
+"MetricGroup": "general",
+"MetricName": "dtlb_miss_rate_percent"
+},
+{
+"BriefDescription": "Flush rate (%)",
+"MetricExpr": "PM_FLUSH * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "general",
+"MetricName": "flush_rate_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (11 to 14) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_11_14_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_11to14_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (15 to 17) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_15_17_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_15to17_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization 18+ as a % of cycles this 
thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_18_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_18plus_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (1 to 2) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_1_2_ENTRIES /  ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_1to2_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (3 to 6) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_3_6_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_3to6_slots_percent"
+},
+{
+"BriefDescription": "GCT slot utilization (7 to 10) as a % of cycles 
this thread had atleast 1 slot valid",
+"MetricExpr": "PM_GCT_UTIL_7_10_ENTRIES / ( PM_RUN_CYC - 
PM_GCT_NOSLOT_CYC) * 100",
+"MetricGroup": "general",
+"MetricName": "gct_util_7to10_slots_percent"
+},
+{
+"BriefDescription": "Avg. group size",
+"MetricExpr": "PM_INST_CMPL / PM_1PLUS_PPC_CMPL",
+"MetricGroup": "general",
+"MetricName": "group_size"
+},
+{
+"BriefDescription": "Instructions per group",
+"MetricExpr": "PM_INST_CMPL / PM_1PLUS_PPC_CMPL",
+"MetricGroup": "general",
+"MetricName": "inst_per_group"
+},
+{
+"BriefDescription": "Instructions per cycles",
+"MetricExpr": "PM_INST_CMPL / PM_CYC",
+"MetricGroup": "general",
+

[PATCH v2 1/4] [powerpc] perf vendor events: Add JSON metrics for POWER8

2019-02-07 Thread Paul Clarke

POWER8 metrics not well publicized.  Some are here:
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- cpi_breakdown
- estimated_dcache_miss_cpi

Signed-off-by: Paul A. Clarke 
---
 .../arch/powerpc/power8/metrics.json  | 461 ++
 1 file changed, 461 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/powerpc/power8/metrics.json

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
new file mode 100644
index ..377b76226c08
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -0,0 +1,461 @@
+[
+{
+"BriefDescription": "Cycles stalled due to CRU or BRU operations",
+"MetricExpr": "PM_CMPLU_STALL_BRU_CRU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_cru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled due to ISU Branch Operations",
+"MetricExpr": "PM_CMPLU_STALL_BRU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles in which a Group Completed",
+"MetricExpr": "PM_GRP_CMPL / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "completion_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by CO queue full",
+"MetricExpr": "PM_CMPLU_STALL_COQ_FULL / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "coq_full_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled due to CRU Operations",
+"MetricExpr": "(PM_CMPLU_STALL_BRU_CRU - PM_CMPLU_STALL_BRU) / 
PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "cru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by flushes",
+"MetricExpr": "PM_CMPLU_STALL_FLUSH / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "flush_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by FXU Multi-Cycle Instructions",
+"MetricExpr": "PM_CMPLU_STALL_FXLONG / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_multi_cyc_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by FXU",
+"MetricExpr": "PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_stall_cpi"
+},
+{
+"BriefDescription": "Other cycles stalled by FXU",
+"MetricExpr": "(PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL) - 
(PM_CMPLU_STALL_FXLONG / PM_RUN_INST_CMPL)",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_stall_other_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty due to Branch Mispredicts",
+"MetricExpr": "PM_GCT_NOSLOT_BR_MPRED / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_br_mpred_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty due to Branch Mispredicts and 
Icache Misses",
+"MetricExpr": "PM_GCT_NOSLOT_BR_MPRED_ICMISS / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_br_mpred_ic_miss_cpi"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "PM_GCT_NOSLOT_CYC / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held",
+"MetricExpr": "(PM_GCT_NOSLOT_DISP_HELD_MAP + 
PM_GCT_NOSLOT_DISP_HELD_SRQ + PM_GCT_NOSLOT_DISP_HELD_ISSQ + 
PM_GCT_NOSLOT_DISP_HELD_OTHER) / PM_RUN_INST_CMPL)",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_disp_held_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held due to 
issue queue",
+"MetricExpr": "PM_GCT_NOSLOT_DISP_HELD_ISSQ / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_disp_held_issq_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held due to 
maps",
+"MetricExpr": "PM_GCT_NOSLOT_DISP_HELD_MAP / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_disp_held_map_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held due to 
syncs and other effects",
+"MetricExpr": "PM_GCT_NOSLOT_DISP_HELD_OTHER / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_disp_held_other_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held due to 
SRQ",
+"MetricExpr": "PM_GCT_NOSLOT_DISP_HELD_SRQ / PM_RUN_INST_CMPL",
+

[PATCH v2 0/4] [powerpc] perf vendor events: Add JSON metrics for POWER8

2019-02-07 Thread Paul Clarke

The patches define metrics and metric groups for computation by "perf" for
POWER8 processors.

Paul Clarke (4):
  [powerpc] perf vendor events: Add JSON metrics for POWER8 1/4
  [powerpc] perf vendor events: Add JSON metrics for POWER8 2/4
  [powerpc] perf vendor events: Add JSON metrics for POWER8 3/4
  [powerpc] perf vendor events: Add JSON metrics for POWER8 4/4

v2:
The content of these patches was sent previously, to LKML and linux-perf-users,
but never showed up at linux-perf-users, so I split it into smaller patches
and am resending.

 .../arch/powerpc/power8/metrics.json  | 2245 +
 1 file changed, 2245 insertions(+)
 create mode 100644 tools/perf/pmu-events/arch/powerpc/power8/metrics.json

-- 
2.17.1

Re: [PATCH 2/3] perf alias: Rebuild alias expression string to make it comparable

2018-06-14 Thread Paul Clarke

On 06/14/2018 06:48 AM, Thomas Richter wrote:
> PMU alias definitions in sysfs files may have spaces, newlines
> and number with leading zeroes. Same alias definitions may
> also appear in JSON files without spaces, etc.
> 
> Scan alias definitions and remove leading zeroes, spaces,
> newlines, etc and rebuild string to make alias->str member
> comparable.
> 
> s390 for example  has terms specified as
> event=0x0091 (read from files ..//events/
> and terms specified as event=0x91 (read from JSON files).
> 
> Signed-off-by: Thomas Richter 
> ---
>  tools/perf/util/pmu.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 26c79a9c4142..da8f243743d3 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -241,9 +241,11 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
>char *metric_expr,
>char *metric_name)
>  {
> + struct parse_events_term *term;
>   struct perf_pmu_alias *alias;
>   int ret;
>   int num;
> + char newval[256];

How was 256 chosen?

> 
>   alias = malloc(sizeof(*alias));
>   if (!alias)
> @@ -262,6 +264,27 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
>   return ret;
>   }
> 
> + /* Scan event and remove leading zeroes, spaces, newlines, some
> +  * platforms have terms specified as
> +  * event=0x0091 (read from files ..//events/
> +  * and terms specified as event=0x91 (read from JSON files).
> +  *
> +  * Rebuild string to make alias->str member comparable.
> +  */
> + memset(newval, 0, sizeof(newval));
> + ret = 0;
> + list_for_each_entry(term, >terms, list) {
> + if (ret)
> + ret += scnprintf(newval + ret, sizeof(newval) - ret,
> +  ",");
> + if (term->type_val == PARSE_EVENTS__TERM_TYPE_NUM)
> + ret += scnprintf(newval + ret, sizeof(newval) - ret,
> +  "%s=%#x", term->config, term->val.num);
> + else if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR)
> + ret += scnprintf(newval + ret, sizeof(newval) - ret,
> +  "%s=%s", term->config, term->val.str);

If we exceed 256, we just suddenly terminate the rebuilding without reporting 
any issues.

> + }
> +
>   alias->name = strdup(name);
>   if (dir) {
>   /*
> @@ -285,7 +308,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
>   snprintf(alias->unit, sizeof(alias->unit), "%s", unit);
>   }
>   alias->per_pkg = perpkg && sscanf(perpkg, "%d", ) == 1 && num == 1;
> - alias->str = strdup(val);
> + alias->str = strdup(newval);
> 
>   list_add_tail(>list, list);
> 

PC

Re: [PATCH 2/3] perf alias: Rebuild alias expression string to make it comparable

2018-06-14 Thread Paul Clarke

On 06/14/2018 06:48 AM, Thomas Richter wrote:
> PMU alias definitions in sysfs files may have spaces, newlines
> and number with leading zeroes. Same alias definitions may
> also appear in JSON files without spaces, etc.
> 
> Scan alias definitions and remove leading zeroes, spaces,
> newlines, etc and rebuild string to make alias->str member
> comparable.
> 
> s390 for example  has terms specified as
> event=0x0091 (read from files ..//events/
> and terms specified as event=0x91 (read from JSON files).
> 
> Signed-off-by: Thomas Richter 
> ---
>  tools/perf/util/pmu.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 26c79a9c4142..da8f243743d3 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -241,9 +241,11 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
>char *metric_expr,
>char *metric_name)
>  {
> + struct parse_events_term *term;
>   struct perf_pmu_alias *alias;
>   int ret;
>   int num;
> + char newval[256];

How was 256 chosen?

> 
>   alias = malloc(sizeof(*alias));
>   if (!alias)
> @@ -262,6 +264,27 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
>   return ret;
>   }
> 
> + /* Scan event and remove leading zeroes, spaces, newlines, some
> +  * platforms have terms specified as
> +  * event=0x0091 (read from files ..//events/
> +  * and terms specified as event=0x91 (read from JSON files).
> +  *
> +  * Rebuild string to make alias->str member comparable.
> +  */
> + memset(newval, 0, sizeof(newval));
> + ret = 0;
> + list_for_each_entry(term, >terms, list) {
> + if (ret)
> + ret += scnprintf(newval + ret, sizeof(newval) - ret,
> +  ",");
> + if (term->type_val == PARSE_EVENTS__TERM_TYPE_NUM)
> + ret += scnprintf(newval + ret, sizeof(newval) - ret,
> +  "%s=%#x", term->config, term->val.num);
> + else if (term->type_val == PARSE_EVENTS__TERM_TYPE_STR)
> + ret += scnprintf(newval + ret, sizeof(newval) - ret,
> +  "%s=%s", term->config, term->val.str);

If we exceed 256, we just suddenly terminate the rebuilding without reporting 
any issues.

> + }
> +
>   alias->name = strdup(name);
>   if (dir) {
>   /*
> @@ -285,7 +308,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
>   snprintf(alias->unit, sizeof(alias->unit), "%s", unit);
>   }
>   alias->per_pkg = perpkg && sscanf(perpkg, "%d", ) == 1 && num == 1;
> - alias->str = strdup(val);
> + alias->str = strdup(newval);
> 
>   list_add_tail(>list, list);
> 

PC

Re: [PATCH 1/3] perf alias: Remove trailing newline when reading sysfs files

2018-06-14 Thread Paul Clarke

On 06/14/2018 06:48 AM, Thomas Richter wrote:
> Remove a trailing newline when reading sysfs file contents
> such as /sys/devices/cpum_cf/events/TX_NC_TEND.
> This show when verbose option -v is used.
> 
> Output before:
> tx_nc_tend -> 'cpum_cf'/'event=0x008d
> '/
> 
> Output after:
> tx_nc_tend -> 'cpum_cf'/'event=0x8d'/
> 
> Signed-off-by: Thomas Richter 
> ---
>  tools/perf/util/pmu.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 7878934ebb23..26c79a9c4142 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -294,7 +294,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
> 
>  static int perf_pmu__new_alias(struct list_head *list, char *dir, char 
> *name, FILE *file)
>  {
> - char buf[256];
> + char *cp, buf[256];
>   int ret;
> 
>   ret = fread(buf, 1, sizeof(buf), file);
> @@ -303,6 +303,11 @@ static int perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name, FI
> 
>   buf[ret] = 0;
> 
> + /* Remove trailing newline from sysfs file */
> + cp = strrchr(buf, '\n');
> + if (cp)
> + *cp = '\0';

A nit, perhaps, but this will search backwards through the entire string if a 
newline is not found, which is the most common case, I presume.  Would it be 
more efficient to just look at the last character?  Something like:
i = strlen(buf);
if (i > 0 && buf[i-1] == '\n')
  buf[i-1] = '\0';

> +
>   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL, 
> NULL,
>NULL, NULL, NULL);
>  }
> 

PC

Re: [PATCH 1/3] perf alias: Remove trailing newline when reading sysfs files

2018-06-14 Thread Paul Clarke

On 06/14/2018 06:48 AM, Thomas Richter wrote:
> Remove a trailing newline when reading sysfs file contents
> such as /sys/devices/cpum_cf/events/TX_NC_TEND.
> This show when verbose option -v is used.
> 
> Output before:
> tx_nc_tend -> 'cpum_cf'/'event=0x008d
> '/
> 
> Output after:
> tx_nc_tend -> 'cpum_cf'/'event=0x8d'/
> 
> Signed-off-by: Thomas Richter 
> ---
>  tools/perf/util/pmu.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index 7878934ebb23..26c79a9c4142 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c
> @@ -294,7 +294,7 @@ static int __perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name,
> 
>  static int perf_pmu__new_alias(struct list_head *list, char *dir, char 
> *name, FILE *file)
>  {
> - char buf[256];
> + char *cp, buf[256];
>   int ret;
> 
>   ret = fread(buf, 1, sizeof(buf), file);
> @@ -303,6 +303,11 @@ static int perf_pmu__new_alias(struct list_head *list, 
> char *dir, char *name, FI
> 
>   buf[ret] = 0;
> 
> + /* Remove trailing newline from sysfs file */
> + cp = strrchr(buf, '\n');
> + if (cp)
> + *cp = '\0';

A nit, perhaps, but this will search backwards through the entire string if a 
newline is not found, which is the most common case, I presume.  Would it be 
more efficient to just look at the last character?  Something like:
i = strlen(buf);
if (i > 0 && buf[i-1] == '\n')
  buf[i-1] = '\0';

> +
>   return __perf_pmu__new_alias(list, dir, name, NULL, buf, NULL, NULL, 
> NULL,
>NULL, NULL, NULL);
>  }
> 

PC

Re: [PATCH 42/46] perf script powerpc: Python script for hypervisor call statistics

2018-06-07 Thread Paul Clarke

On 06/07/2018 12:34 AM, Ravi Bangoria wrote:
> On 06/06/2018 08:23 PM, Paul Clarke wrote:
>> On 06/05/2018 12:50 PM, Arnaldo Carvalho de Melo wrote:
>>> From: Ravi Bangoria 
>>>
>>> Add python script to show hypervisor call statistics. Ex,
>>>
>>>   # perf record -a -e "{powerpc:hcall_entry,powerpc:hcall_exit}"
>>>   # perf script -s scripts/python/powerpc-hcalls.py
>>> hcallcount   min(ns)   max(ns)   avg(ns)
>>> 
>>> H_RANDOM82   838  1164   904
>>> H_PUT_TCE   47  1078  5928  2003
>>> H_EOI  266  1336  3546  1654
>>> H_ENTER 28  1646  4038  1952
>>> H_PUT_TCE_INDIRECT 230  2166 18168  6109
>>> H_IPI  238  1072  3232  1688
>>> H_SEND_LOGICAL_LAN  42  5488 21366  7694
>>> H_STUFF_TCE294   986  6210  3591
>>> H_XIRR 266  2286  6990  3783
>>> H_PROTECT   10  2196  3556  2555
>>> H_VIO_SIGNAL   294  1028  2784  1311
>>> H_ADD_LOGICAL_LAN_BUFFER53  1978  3450  2600
>>> H_SEND_CRQ  77  1762  7240  2447
>>
>> This translation from HCALL code to mnemonic is more generally useful.  Is 
>> there a good way to make the "hcall_table_lookup" function more generally 
>> available, like "syscall_name" in 
>> scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py ?  It's even simpler 
>> than the syscall ID-to-name mapping, because the HCALL codes are constant, 
>> unlike syscall IDs which vary between arches.
>>
> 
> Right, but I don't see any other python script for hcalls. So, I thought
> to add it in the script itself. Let me know if you are planning to add
> any :) We will move it in a generic module.

We're already doing the same thing in an external script.  
(https://github.com/open-power-sdk/curt/blob/master/curt.py#L264 revision 
107c97c3aadba3177bc8cf35b06ba165e6ac557f.)

...which reminds me that I should consider sending that script to 
linux-perf-users to see if it's interesting enough to be included upstream.

PC

Re: [PATCH 42/46] perf script powerpc: Python script for hypervisor call statistics

2018-06-07 Thread Paul Clarke

On 06/07/2018 12:34 AM, Ravi Bangoria wrote:
> On 06/06/2018 08:23 PM, Paul Clarke wrote:
>> On 06/05/2018 12:50 PM, Arnaldo Carvalho de Melo wrote:
>>> From: Ravi Bangoria 
>>>
>>> Add python script to show hypervisor call statistics. Ex,
>>>
>>>   # perf record -a -e "{powerpc:hcall_entry,powerpc:hcall_exit}"
>>>   # perf script -s scripts/python/powerpc-hcalls.py
>>> hcallcount   min(ns)   max(ns)   avg(ns)
>>> 
>>> H_RANDOM82   838  1164   904
>>> H_PUT_TCE   47  1078  5928  2003
>>> H_EOI  266  1336  3546  1654
>>> H_ENTER 28  1646  4038  1952
>>> H_PUT_TCE_INDIRECT 230  2166 18168  6109
>>> H_IPI  238  1072  3232  1688
>>> H_SEND_LOGICAL_LAN  42  5488 21366  7694
>>> H_STUFF_TCE294   986  6210  3591
>>> H_XIRR 266  2286  6990  3783
>>> H_PROTECT   10  2196  3556  2555
>>> H_VIO_SIGNAL   294  1028  2784  1311
>>> H_ADD_LOGICAL_LAN_BUFFER53  1978  3450  2600
>>> H_SEND_CRQ  77  1762  7240  2447
>>
>> This translation from HCALL code to mnemonic is more generally useful.  Is 
>> there a good way to make the "hcall_table_lookup" function more generally 
>> available, like "syscall_name" in 
>> scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py ?  It's even simpler 
>> than the syscall ID-to-name mapping, because the HCALL codes are constant, 
>> unlike syscall IDs which vary between arches.
>>
> 
> Right, but I don't see any other python script for hcalls. So, I thought
> to add it in the script itself. Let me know if you are planning to add
> any :) We will move it in a generic module.

We're already doing the same thing in an external script.  
(https://github.com/open-power-sdk/curt/blob/master/curt.py#L264 revision 
107c97c3aadba3177bc8cf35b06ba165e6ac557f.)

...which reminds me that I should consider sending that script to 
linux-perf-users to see if it's interesting enough to be included upstream.

PC

Re: [PATCH 42/46] perf script powerpc: Python script for hypervisor call statistics

2018-06-06 Thread Paul Clarke

On 06/05/2018 12:50 PM, Arnaldo Carvalho de Melo wrote:
> From: Ravi Bangoria 
> 
> Add python script to show hypervisor call statistics. Ex,
> 
>   # perf record -a -e "{powerpc:hcall_entry,powerpc:hcall_exit}"
>   # perf script -s scripts/python/powerpc-hcalls.py
> hcallcount   min(ns)   max(ns)   avg(ns)
> 
> H_RANDOM82   838  1164   904
> H_PUT_TCE   47  1078  5928  2003
> H_EOI  266  1336  3546  1654
> H_ENTER 28  1646  4038  1952
> H_PUT_TCE_INDIRECT 230  2166 18168  6109
> H_IPI  238  1072  3232  1688
> H_SEND_LOGICAL_LAN  42  5488 21366  7694
> H_STUFF_TCE294   986  6210  3591
> H_XIRR 266  2286  6990  3783
> H_PROTECT   10  2196  3556  2555
> H_VIO_SIGNAL   294  1028  2784  1311
> H_ADD_LOGICAL_LAN_BUFFER53  1978  3450  2600
> H_SEND_CRQ  77  1762  7240  2447

This translation from HCALL code to mnemonic is more generally useful.  Is 
there a good way to make the "hcall_table_lookup" function more generally 
available, like "syscall_name" in 
scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py ?  It's even simpler than 
the syscall ID-to-name mapping, because the HCALL codes are constant, unlike 
syscall IDs which vary between arches.

> diff --git a/tools/perf/scripts/python/powerpc-hcalls.py 
> b/tools/perf/scripts/python/powerpc-hcalls.py
> new file mode 100644
> index ..00e0e7476e55
> --- /dev/null
> +++ b/tools/perf/scripts/python/powerpc-hcalls.py
> @@ -0,0 +1,200 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018 Ravi Bangoria, IBM Corporation
> +#
> +# Hypervisor call statisics
> +
> +import os
> +import sys
> +
> +sys.path.append(os.environ['PERF_EXEC_PATH'] + \
> + '/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
> +
> +from perf_trace_context import *
> +from Core import *
> +from Util import *
> +
> +# output: {
> +#opcode: {
> +#'min': minimum time nsec
> +#'max': maximum time nsec
> +#'time': average time nsec
> +#'cnt': counter
> +#} ...
> +# }
> +output = {}
> +
> +# d_enter: {
> +#cpu: {
> +#opcode: nsec
> +#} ...
> +# }
> +d_enter = {}
> +
> +hcall_table = {
> + 4: 'H_REMOVE',
> + 8: 'H_ENTER',
> + 12: 'H_READ',
> + 16: 'H_CLEAR_MOD',
> + 20: 'H_CLEAR_REF',
> + 24: 'H_PROTECT',
> + 28: 'H_GET_TCE',
> + 32: 'H_PUT_TCE',
> + 36: 'H_SET_SPRG0',
> + 40: 'H_SET_DABR',
> + 44: 'H_PAGE_INIT',
> + 48: 'H_SET_ASR',
> + 52: 'H_ASR_ON',
> + 56: 'H_ASR_OFF',
> + 60: 'H_LOGICAL_CI_LOAD',
> + 64: 'H_LOGICAL_CI_STORE',
> + 68: 'H_LOGICAL_CACHE_LOAD',
> + 72: 'H_LOGICAL_CACHE_STORE',
> + 76: 'H_LOGICAL_ICBI',
> + 80: 'H_LOGICAL_DCBF',
> + 84: 'H_GET_TERM_CHAR',
> + 88: 'H_PUT_TERM_CHAR',
> + 92: 'H_REAL_TO_LOGICAL',
> + 96: 'H_HYPERVISOR_DATA',
> + 100: 'H_EOI',
> + 104: 'H_CPPR',
> + 108: 'H_IPI',
> + 112: 'H_IPOLL',
> + 116: 'H_XIRR',
> + 120: 'H_MIGRATE_DMA',
> + 124: 'H_PERFMON',
> + 220: 'H_REGISTER_VPA',
> + 224: 'H_CEDE',
> + 228: 'H_CONFER',
> + 232: 'H_PROD',
> + 236: 'H_GET_PPP',
> + 240: 'H_SET_PPP',
> + 244: 'H_PURR',
> + 248: 'H_PIC',
> + 252: 'H_REG_CRQ',
> + 256: 'H_FREE_CRQ',
> + 260: 'H_VIO_SIGNAL',
> + 264: 'H_SEND_CRQ',
> + 272: 'H_COPY_RDMA',
> + 276: 'H_REGISTER_LOGICAL_LAN',
> + 280: 'H_FREE_LOGICAL_LAN',
> + 284: 'H_ADD_LOGICAL_LAN_BUFFER',
> + 288: 'H_SEND_LOGICAL_LAN',
> + 292: 'H_BULK_REMOVE',
> + 304: 'H_MULTICAST_CTRL',
> + 308: 'H_SET_XDABR',
> + 312: 'H_STUFF_TCE',
> + 316: 'H_PUT_TCE_INDIRECT',
> + 332: 'H_CHANGE_LOGICAL_LAN_MAC',
> + 336: 'H_VTERM_PARTNER_INFO',
> + 340: 'H_REGISTER_VTERM',
> + 344: 'H_FREE_VTERM',
> + 348: 'H_RESET_EVENTS',
> + 352: 'H_ALLOC_RESOURCE',
> + 356: 'H_FREE_RESOURCE',
> + 360: 'H_MODIFY_QP',
> + 364: 'H_QUERY_QP',
> + 368: 'H_REREGISTER_PMR',
> + 372: 'H_REGISTER_SMR',
> + 376: 'H_QUERY_MR',
> + 380: 'H_QUERY_MW',
> + 384: 'H_QUERY_HCA',
> + 388: 'H_QUERY_PORT',
> + 392: 'H_MODIFY_PORT',
> + 396: 'H_DEFINE_AQP1',
> + 400: 'H_GET_TRACE_BUFFER',
> + 404: 'H_DEFINE_AQP0',
> + 408: 'H_RESIZE_MR',
> + 412: 'H_ATTACH_MCQP',
> + 416: 'H_DETACH_MCQP',
> + 420: 'H_CREATE_RPT',
> + 424: 'H_REMOVE_RPT',
> + 428:

Re: [PATCH 42/46] perf script powerpc: Python script for hypervisor call statistics

2018-06-06 Thread Paul Clarke

On 06/05/2018 12:50 PM, Arnaldo Carvalho de Melo wrote:
> From: Ravi Bangoria 
> 
> Add python script to show hypervisor call statistics. Ex,
> 
>   # perf record -a -e "{powerpc:hcall_entry,powerpc:hcall_exit}"
>   # perf script -s scripts/python/powerpc-hcalls.py
> hcallcount   min(ns)   max(ns)   avg(ns)
> 
> H_RANDOM82   838  1164   904
> H_PUT_TCE   47  1078  5928  2003
> H_EOI  266  1336  3546  1654
> H_ENTER 28  1646  4038  1952
> H_PUT_TCE_INDIRECT 230  2166 18168  6109
> H_IPI  238  1072  3232  1688
> H_SEND_LOGICAL_LAN  42  5488 21366  7694
> H_STUFF_TCE294   986  6210  3591
> H_XIRR 266  2286  6990  3783
> H_PROTECT   10  2196  3556  2555
> H_VIO_SIGNAL   294  1028  2784  1311
> H_ADD_LOGICAL_LAN_BUFFER53  1978  3450  2600
> H_SEND_CRQ  77  1762  7240  2447

This translation from HCALL code to mnemonic is more generally useful.  Is 
there a good way to make the "hcall_table_lookup" function more generally 
available, like "syscall_name" in 
scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py ?  It's even simpler than 
the syscall ID-to-name mapping, because the HCALL codes are constant, unlike 
syscall IDs which vary between arches.

> diff --git a/tools/perf/scripts/python/powerpc-hcalls.py 
> b/tools/perf/scripts/python/powerpc-hcalls.py
> new file mode 100644
> index ..00e0e7476e55
> --- /dev/null
> +++ b/tools/perf/scripts/python/powerpc-hcalls.py
> @@ -0,0 +1,200 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (C) 2018 Ravi Bangoria, IBM Corporation
> +#
> +# Hypervisor call statisics
> +
> +import os
> +import sys
> +
> +sys.path.append(os.environ['PERF_EXEC_PATH'] + \
> + '/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
> +
> +from perf_trace_context import *
> +from Core import *
> +from Util import *
> +
> +# output: {
> +#opcode: {
> +#'min': minimum time nsec
> +#'max': maximum time nsec
> +#'time': average time nsec
> +#'cnt': counter
> +#} ...
> +# }
> +output = {}
> +
> +# d_enter: {
> +#cpu: {
> +#opcode: nsec
> +#} ...
> +# }
> +d_enter = {}
> +
> +hcall_table = {
> + 4: 'H_REMOVE',
> + 8: 'H_ENTER',
> + 12: 'H_READ',
> + 16: 'H_CLEAR_MOD',
> + 20: 'H_CLEAR_REF',
> + 24: 'H_PROTECT',
> + 28: 'H_GET_TCE',
> + 32: 'H_PUT_TCE',
> + 36: 'H_SET_SPRG0',
> + 40: 'H_SET_DABR',
> + 44: 'H_PAGE_INIT',
> + 48: 'H_SET_ASR',
> + 52: 'H_ASR_ON',
> + 56: 'H_ASR_OFF',
> + 60: 'H_LOGICAL_CI_LOAD',
> + 64: 'H_LOGICAL_CI_STORE',
> + 68: 'H_LOGICAL_CACHE_LOAD',
> + 72: 'H_LOGICAL_CACHE_STORE',
> + 76: 'H_LOGICAL_ICBI',
> + 80: 'H_LOGICAL_DCBF',
> + 84: 'H_GET_TERM_CHAR',
> + 88: 'H_PUT_TERM_CHAR',
> + 92: 'H_REAL_TO_LOGICAL',
> + 96: 'H_HYPERVISOR_DATA',
> + 100: 'H_EOI',
> + 104: 'H_CPPR',
> + 108: 'H_IPI',
> + 112: 'H_IPOLL',
> + 116: 'H_XIRR',
> + 120: 'H_MIGRATE_DMA',
> + 124: 'H_PERFMON',
> + 220: 'H_REGISTER_VPA',
> + 224: 'H_CEDE',
> + 228: 'H_CONFER',
> + 232: 'H_PROD',
> + 236: 'H_GET_PPP',
> + 240: 'H_SET_PPP',
> + 244: 'H_PURR',
> + 248: 'H_PIC',
> + 252: 'H_REG_CRQ',
> + 256: 'H_FREE_CRQ',
> + 260: 'H_VIO_SIGNAL',
> + 264: 'H_SEND_CRQ',
> + 272: 'H_COPY_RDMA',
> + 276: 'H_REGISTER_LOGICAL_LAN',
> + 280: 'H_FREE_LOGICAL_LAN',
> + 284: 'H_ADD_LOGICAL_LAN_BUFFER',
> + 288: 'H_SEND_LOGICAL_LAN',
> + 292: 'H_BULK_REMOVE',
> + 304: 'H_MULTICAST_CTRL',
> + 308: 'H_SET_XDABR',
> + 312: 'H_STUFF_TCE',
> + 316: 'H_PUT_TCE_INDIRECT',
> + 332: 'H_CHANGE_LOGICAL_LAN_MAC',
> + 336: 'H_VTERM_PARTNER_INFO',
> + 340: 'H_REGISTER_VTERM',
> + 344: 'H_FREE_VTERM',
> + 348: 'H_RESET_EVENTS',
> + 352: 'H_ALLOC_RESOURCE',
> + 356: 'H_FREE_RESOURCE',
> + 360: 'H_MODIFY_QP',
> + 364: 'H_QUERY_QP',
> + 368: 'H_REREGISTER_PMR',
> + 372: 'H_REGISTER_SMR',
> + 376: 'H_QUERY_MR',
> + 380: 'H_QUERY_MW',
> + 384: 'H_QUERY_HCA',
> + 388: 'H_QUERY_PORT',
> + 392: 'H_MODIFY_PORT',
> + 396: 'H_DEFINE_AQP1',
> + 400: 'H_GET_TRACE_BUFFER',
> + 404: 'H_DEFINE_AQP0',
> + 408: 'H_RESIZE_MR',
> + 412: 'H_ATTACH_MCQP',
> + 416: 'H_DETACH_MCQP',
> + 420: 'H_CREATE_RPT',
> + 424: 'H_REMOVE_RPT',
> + 428:

Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

2017-12-08 Thread Paul Clarke



On 12/07/2017 09:01 PM, Masami Hiramatsu wrote:
> On Thu, 7 Dec 2017 10:34:51 -0600
> Paul Clarke <p...@us.ibm.com> wrote:
>> On 12/07/2017 01:20 AM, Masami Hiramatsu wrote:
>>> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
>>> automatic generated event name. This fixes wildcard event
>>> adding like below case;
>>>
>>>   =
>>>   # perf probe -x /lib64/libc-2.25.so malloc*
>>>   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
>>> Error: Failed to add events.
>>>   =
>>>
>>> This failure was caused by a versioned suffix symbol.
>>> With this fix, perf probe automatically cuts the
>>> suffix after @ as below.
>>>
>>>   =
>>>   # ./perf probe -x /lib64/libc-2.25.so malloc*
>>>   Added new events:
>>> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)
>>>
>>>   You can now use it in all perf tools, such as:
>>>
>>>   perf record -e probe_libc:malloc_set_state -aR sleep 1
>>>
>>>   =
>>
>> I think this will still fall over for a case where there are multiple 
>> versions of the same base symbol, like:
>>
>> $ nm /lib64/libc.so.6 | egrep ' sched_getaffinity'
>> 00134430 T sched_getaffinity@GLIBC_2.3.3
>> 000dcf00 T sched_getaffinity@@GLIBC_2.3.4
> 
> No, in that case perf probe adds number suffix (_1, _2...) for new events :)
> 
> This feature (number suffix) is anyway required for the case that inlined
> function is spreaded in multiple places. I think this is natural for perf 
> probe.

I can live with that.

Is the versioning tag retained for display with "perf probe -l" display, so the 
probe points can be distinguished?

In other words, will one see:
# perf probe -l
  probe_libc:sched_getaffinity (on sched_getaffinity@GLIBC_2.3.3 in 
/usr/lib64/libc-2.17.so)
  probe_libc:sched_getaffinity_1 (on sched_getaffinity@@GLIBC_2.3.4 in 
/usr/lib64/libc-2.17.so)
or
# perf probe -l
  probe_libc:sched_getaffinity (on sched_getaffinity in /usr/lib64/libc-2.17.so)
  probe_libc:sched_getaffinity_1 (on sched_getaffinity in 
/usr/lib64/libc-2.17.so)

PC

Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

2017-12-08 Thread Paul Clarke



On 12/07/2017 09:01 PM, Masami Hiramatsu wrote:
> On Thu, 7 Dec 2017 10:34:51 -0600
> Paul Clarke  wrote:
>> On 12/07/2017 01:20 AM, Masami Hiramatsu wrote:
>>> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
>>> automatic generated event name. This fixes wildcard event
>>> adding like below case;
>>>
>>>   =
>>>   # perf probe -x /lib64/libc-2.25.so malloc*
>>>   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
>>> Error: Failed to add events.
>>>   =
>>>
>>> This failure was caused by a versioned suffix symbol.
>>> With this fix, perf probe automatically cuts the
>>> suffix after @ as below.
>>>
>>>   =
>>>   # ./perf probe -x /lib64/libc-2.25.so malloc*
>>>   Added new events:
>>> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
>>> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)
>>>
>>>   You can now use it in all perf tools, such as:
>>>
>>>   perf record -e probe_libc:malloc_set_state -aR sleep 1
>>>
>>>   =
>>
>> I think this will still fall over for a case where there are multiple 
>> versions of the same base symbol, like:
>>
>> $ nm /lib64/libc.so.6 | egrep ' sched_getaffinity'
>> 00134430 T sched_getaffinity@GLIBC_2.3.3
>> 000dcf00 T sched_getaffinity@@GLIBC_2.3.4
> 
> No, in that case perf probe adds number suffix (_1, _2...) for new events :)
> 
> This feature (number suffix) is anyway required for the case that inlined
> function is spreaded in multiple places. I think this is natural for perf 
> probe.

I can live with that.

Is the versioning tag retained for display with "perf probe -l" display, so the 
probe points can be distinguished?

In other words, will one see:
# perf probe -l
  probe_libc:sched_getaffinity (on sched_getaffinity@GLIBC_2.3.3 in 
/usr/lib64/libc-2.17.so)
  probe_libc:sched_getaffinity_1 (on sched_getaffinity@@GLIBC_2.3.4 in 
/usr/lib64/libc-2.17.so)
or
# perf probe -l
  probe_libc:sched_getaffinity (on sched_getaffinity in /usr/lib64/libc-2.17.so)
  probe_libc:sched_getaffinity_1 (on sched_getaffinity in 
/usr/lib64/libc-2.17.so)

PC

Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

2017-12-07 Thread Paul Clarke



On 12/07/2017 10:56 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Dec 07, 2017 at 04:20:28PM +0900, Masami Hiramatsu escreveu:
>> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
>> automatic generated event name. This fixes wildcard event
>> adding like below case;
>>
>>   =
>>   # perf probe -x /lib64/libc-2.25.so malloc*
>>   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
>> Error: Failed to add events.
>>   =
>>
>> This failure was caused by a versioned suffix symbol.
>> With this fix, perf probe automatically cuts the
>> suffix after @ as below.
>>
>>   =
>>   # ./perf probe -x /lib64/libc-2.25.so malloc*
>>   Added new events:
>> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)
> 
> Thanks for working on this! I'm now going over it, and one thing I
> noticed was that the (on malloc*) on all the entries matched by that
> wildcard, can I suggest that you expand it there as well? I.e.
> 
>  probe_libc:malloc_set_state (on malloc_set_state in 
> /usr/lib64/libc-2.25.so)
> 
> This way we'll now when aliases are used, and also for the versioning
> case, i.e. to which version is a probe pointing?
> 
> See also Paul Clarke's question and suggestion, which I agree, i.e.
> instead of chopping off the version, just replace the chars with valid
> ones or better, do what Paul suggests, be more flexible in interpreting
> @, i.e. if it is a number and/or fails to point to any file, interpret
> it as versioning.

It's a nit, and subjective, but I'd favor checking for versioning first, then 
file.  The namespaces are very unlikely to intersect, but I could foresee 
symbols like "sym@implA.c" and "sym@implB.c" more likely than a symbol in a 
file "GLIBC_2.2.5".

Perhaps straying toward bikeshedding...

PC

Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

2017-12-07 Thread Paul Clarke



On 12/07/2017 10:56 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Dec 07, 2017 at 04:20:28PM +0900, Masami Hiramatsu escreveu:
>> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
>> automatic generated event name. This fixes wildcard event
>> adding like below case;
>>
>>   =
>>   # perf probe -x /lib64/libc-2.25.so malloc*
>>   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
>> Error: Failed to add events.
>>   =
>>
>> This failure was caused by a versioned suffix symbol.
>> With this fix, perf probe automatically cuts the
>> suffix after @ as below.
>>
>>   =
>>   # ./perf probe -x /lib64/libc-2.25.so malloc*
>>   Added new events:
>> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
>> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)
> 
> Thanks for working on this! I'm now going over it, and one thing I
> noticed was that the (on malloc*) on all the entries matched by that
> wildcard, can I suggest that you expand it there as well? I.e.
> 
>  probe_libc:malloc_set_state (on malloc_set_state in 
> /usr/lib64/libc-2.25.so)
> 
> This way we'll now when aliases are used, and also for the versioning
> case, i.e. to which version is a probe pointing?
> 
> See also Paul Clarke's question and suggestion, which I agree, i.e.
> instead of chopping off the version, just replace the chars with valid
> ones or better, do what Paul suggests, be more flexible in interpreting
> @, i.e. if it is a number and/or fails to point to any file, interpret
> it as versioning.

It's a nit, and subjective, but I'd favor checking for versioning first, then 
file.  The namespaces are very unlikely to intersect, but I could foresee 
symbols like "sym@implA.c" and "sym@implB.c" more likely than a symbol in a 
file "GLIBC_2.2.5".

Perhaps straying toward bikeshedding...

PC

Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

2017-12-07 Thread Paul Clarke



On 12/07/2017 01:20 AM, Masami Hiramatsu wrote:
> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
> automatic generated event name. This fixes wildcard event
> adding like below case;
> 
>   =
>   # perf probe -x /lib64/libc-2.25.so malloc*
>   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
> Error: Failed to add events.
>   =
> 
> This failure was caused by a versioned suffix symbol.
> With this fix, perf probe automatically cuts the
> suffix after @ as below.
> 
>   =
>   # ./perf probe -x /lib64/libc-2.25.so malloc*
>   Added new events:
> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)
> 
>   You can now use it in all perf tools, such as:
> 
> perf record -e probe_libc:malloc_set_state -aR sleep 1
> 
>   =

I think this will still fall over for a case where there are multiple versions 
of the same base symbol, like:

$ nm /lib64/libc.so.6 | egrep ' sched_getaffinity'
00134430 T sched_getaffinity@GLIBC_2.3.3
000dcf00 T sched_getaffinity@@GLIBC_2.3.4

Should we retain the versioning string in some form?  
"sched_getaffinity--GLIBC_2.3.4"?  Should we instead interpret the '@' symbol 
more flexibly, so maybe first assume it is a version string, and if not found, 
try to see if it's a valid "@SRC" specification?

PC

Re: [PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

2017-12-07 Thread Paul Clarke



On 12/07/2017 01:20 AM, Masami Hiramatsu wrote:
> Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
> automatic generated event name. This fixes wildcard event
> adding like below case;
> 
>   =
>   # perf probe -x /lib64/libc-2.25.so malloc*
>   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
> Error: Failed to add events.
>   =
> 
> This failure was caused by a versioned suffix symbol.
> With this fix, perf probe automatically cuts the
> suffix after @ as below.
> 
>   =
>   # ./perf probe -x /lib64/libc-2.25.so malloc*
>   Added new events:
> probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
> probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)
> 
>   You can now use it in all perf tools, such as:
> 
> perf record -e probe_libc:malloc_set_state -aR sleep 1
> 
>   =

I think this will still fall over for a case where there are multiple versions 
of the same base symbol, like:

$ nm /lib64/libc.so.6 | egrep ' sched_getaffinity'
00134430 T sched_getaffinity@GLIBC_2.3.3
000dcf00 T sched_getaffinity@@GLIBC_2.3.4

Should we retain the versioning string in some form?  
"sched_getaffinity--GLIBC_2.3.4"?  Should we instead interpret the '@' symbol 
more flexibly, so maybe first assume it is a version string, and if not found, 
try to see if it's a valid "@SRC" specification?

PC

Re: [PATCH] perf report: don't crash on invalid maps in `-g srcline` mode

2017-05-11 Thread Paul Clarke

On 05/09/2017 03:50 PM, Milian Wolff wrote:
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 9ab68682c6d0..295f0846fd84 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -642,13 +642,22 @@ static enum match_result match_chain_strings(const char 
> *left,
>  static enum match_result match_chain_srcline(struct callchain_cursor_node 
> *node,
>struct callchain_list *cnode)
>  {
> - char *left = get_srcline(cnode->ms.map->dso,
> -  map__rip_2objdump(cnode->ms.map, cnode->ip),
> -  cnode->ms.sym, true, false);
> - char *right = get_srcline(node->map->dso,
> -   map__rip_2objdump(node->map, node->ip),
> -   node->sym, true, false);
> - enum match_result ret = match_chain_strings(left, right);
> + char *left = NULL;
> + char *right = NULL;

nit: the above two initializations are unnecessary.

> + enum match_result ret = MATCH_ERROR;
> +
> + if (!node->map || !cnode->ms.map)
> + return ret;
> +
> + left = get_srcline(cnode->ms.map->dso,
> +map__rip_2objdump(cnode->ms.map, cnode->ip),
> +cnode->ms.sym, true, false);
> +
> + right = get_srcline(node->map->dso,
> + map__rip_2objdump(node->map, node->ip),
> + node->sym, true, false);
> +
> + ret = match_chain_strings(left, right);
> 
>   free_srcline(left);
>   free_srcline(right);

PC

Re: [PATCH] perf report: don't crash on invalid maps in `-g srcline` mode

2017-05-11 Thread Paul Clarke

On 05/09/2017 03:50 PM, Milian Wolff wrote:
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 9ab68682c6d0..295f0846fd84 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -642,13 +642,22 @@ static enum match_result match_chain_strings(const char 
> *left,
>  static enum match_result match_chain_srcline(struct callchain_cursor_node 
> *node,
>struct callchain_list *cnode)
>  {
> - char *left = get_srcline(cnode->ms.map->dso,
> -  map__rip_2objdump(cnode->ms.map, cnode->ip),
> -  cnode->ms.sym, true, false);
> - char *right = get_srcline(node->map->dso,
> -   map__rip_2objdump(node->map, node->ip),
> -   node->sym, true, false);
> - enum match_result ret = match_chain_strings(left, right);
> + char *left = NULL;
> + char *right = NULL;

nit: the above two initializations are unnecessary.

> + enum match_result ret = MATCH_ERROR;
> +
> + if (!node->map || !cnode->ms.map)
> + return ret;
> +
> + left = get_srcline(cnode->ms.map->dso,
> +map__rip_2objdump(cnode->ms.map, cnode->ip),
> +cnode->ms.sym, true, false);
> +
> + right = get_srcline(node->map->dso,
> + map__rip_2objdump(node->map, node->ip),
> + node->sym, true, false);
> +
> + ret = match_chain_strings(left, right);
> 
>   free_srcline(left);
>   free_srcline(right);

PC

[tip:perf/urgent] perf symbols: Allow user probes on versioned symbols

2017-05-03 Thread tip-bot for Paul Clarke

Commit-ID:  d80406453ad4a69932dc17a617d5b7bc7ae80b8f
Gitweb: http://git.kernel.org/tip/d80406453ad4a69932dc17a617d5b7bc7ae80b8f
Author: Paul Clarke <p...@us.ibm.com>
AuthorDate: Tue, 25 Apr 2017 13:15:49 -0500
Committer:  Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Tue, 2 May 2017 18:23:11 -0300

perf symbols: Allow user probes on versioned symbols

Symbol versioning, as in glibc, results in symbols being defined as:

  @[@]

(Note that "@@" identifies a default symbol, if the symbol name is
repeated.)

perf is currently unable to deal with this, and is unable to create user
probes at such symbols:

  --
  $ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
  8d30 t __pthread_create_2_1
  8d30 T pthread_create@@GLIBC_2.17
  $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
  probe-definition(0): pthread_create
  symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
  0 arguments
  Open Debuginfo file: 
/usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
  Try to find probe point from debuginfo.
  Probe point 'pthread_create' not found.
 Error: Failed to add events. Reason: No such file or directory (Code: -2)
  --

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:

  --
  $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
  probe-definition(0): pthread_create@@GLIBC_2.17
  Semantic error :SRC@SRC is not allowed.
  0 arguments
 Error: Command Parse Error. Reason: Invalid argument (Code: -22)
  --

This patch ignores versioning for default symbols, thus allowing probes to be
created for these symbols:

  --
  $ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
  Added new event:
 probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

  You can now use it in all perf tools, such as:

   perf record -e probe_libpthread:pthread_create -aR sleep 1

  $ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
  $ /usr/bin/sudo ./perf script
   test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
   test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
  $ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
  Removed event: probe_libpthread:pthread_create
  --

Committer note:

Change the variable storing the result of strlen() to 'int', to fix the build
on debian:experimental-x-mipsel, fedora:24-x-ARC-uClibc, ubuntu:16.04-x-arm,
etc:

  util/symbol.c: In function 'symbol__match_symbol_name':
  util/symbol.c:422:11: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (len < versioning - name)
 ^

Signed-off-by: Paul A. Clarke <p...@us.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <a...@redhat.com>
Acked-by: Masami Hiramatsu <mhira...@kernel.org>
Cc: David Ahern <dsah...@gmail.com>
Link: http://lkml.kernel.org/r/c2b18d9c-17f8-9285-4868-f58b6359c...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 61 +++--
 tools/perf/util/symbol.h| 11 ++
 5 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..bf9a259 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
return strcmp(namea, nameb);
 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index ebfa5d9..2179b2d 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(m

[tip:perf/urgent] perf symbols: Allow user probes on versioned symbols

2017-05-03 Thread tip-bot for Paul Clarke

Commit-ID:  d80406453ad4a69932dc17a617d5b7bc7ae80b8f
Gitweb: http://git.kernel.org/tip/d80406453ad4a69932dc17a617d5b7bc7ae80b8f
Author: Paul Clarke 
AuthorDate: Tue, 25 Apr 2017 13:15:49 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 2 May 2017 18:23:11 -0300

perf symbols: Allow user probes on versioned symbols

Symbol versioning, as in glibc, results in symbols being defined as:

  @[@]

(Note that "@@" identifies a default symbol, if the symbol name is
repeated.)

perf is currently unable to deal with this, and is unable to create user
probes at such symbols:

  --
  $ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
  8d30 t __pthread_create_2_1
  8d30 T pthread_create@@GLIBC_2.17
  $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
  probe-definition(0): pthread_create
  symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
  0 arguments
  Open Debuginfo file: 
/usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
  Try to find probe point from debuginfo.
  Probe point 'pthread_create' not found.
 Error: Failed to add events. Reason: No such file or directory (Code: -2)
  --

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:

  --
  $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
  probe-definition(0): pthread_create@@GLIBC_2.17
  Semantic error :SRC@SRC is not allowed.
  0 arguments
 Error: Command Parse Error. Reason: Invalid argument (Code: -22)
  --

This patch ignores versioning for default symbols, thus allowing probes to be
created for these symbols:

  --
  $ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
  Added new event:
 probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

  You can now use it in all perf tools, such as:

   perf record -e probe_libpthread:pthread_create -aR sleep 1

  $ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
  $ /usr/bin/sudo ./perf script
   test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
   test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
  $ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
  Removed event: probe_libpthread:pthread_create
  --

Committer note:

Change the variable storing the result of strlen() to 'int', to fix the build
on debian:experimental-x-mipsel, fedora:24-x-ARC-uClibc, ubuntu:16.04-x-arm,
etc:

  util/symbol.c: In function 'symbol__match_symbol_name':
  util/symbol.c:422:11: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (len < versioning - name)
 ^

Signed-off-by: Paul A. Clarke 
Tested-by: Arnaldo Carvalho de Melo 
Acked-by: Masami Hiramatsu 
Cc: David Ahern 
Link: http://lkml.kernel.org/r/c2b18d9c-17f8-9285-4868-f58b6359c...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 61 +++--
 tools/perf/util/symbol.h| 11 ++
 5 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..bf9a259 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
return strcmp(namea, nameb);
 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index ebfa5d9..2179b2d 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..f9e8ac8 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,

Re: [PATCH v6] Allow user probes on versioned symbols

2017-04-25 Thread Paul Clarke

On 04/24/2017 11:34 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 13, 2017 at 12:03:13PM -0500, Paul Clarke escreveu:
>> v4:
>> - rebased to acme/perf/core
> 
> Are you sure?
> 
> [acme@jouet linux]$ patch -p1 < /wb/1.patch 
> patching file tools/perf/arch/powerpc/util/sym-handling.c
> Hunk #1 FAILED at 52.
> 1 out of 1 hunk FAILED -- saving rejects to file 
> tools/perf/arch/powerpc/util/sym-handling.c.rej
> patching file tools/perf/util/map.c
> Hunk #1 FAILED at 325.
> 1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/map.c.rej
> patching file tools/perf/util/map.h
> Hunk #1 FAILED at 130.
> 1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/map.h.rej
> patching file tools/perf/util/symbol.c
> Hunk #1 FAILED at 87.
> Hunk #2 FAILED at 396.
> Hunk #3 FAILED at 411.
> Hunk #4 FAILED at 424.
> Hunk #5 FAILED at 500.
> 5 out of 5 hunks FAILED -- saving rejects to file tools/perf/util/symbol.c.rej
> patching file tools/perf/util/symbol.h
> Hunk #1 FAILED at 348.
> 1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/symbol.h.rej
> [acme@jouet linux]$ 

Sigh. It worked for me, with some offsets.  It's very likely I'm doing 
something wrong, but I don't know what.  (Apologies, if so.)  I generated a new 
patch (with new offsets, attached), and it works here;
--
~$ git clone -b perf/core 
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Cloning into 'linux'...
remote: Counting objects: 5284773, done.
remote: Compressing objects: 100% (805895/805895), done.
remote: Total 5284773 (delta 4438260), reused 5284366 (delta 4437981)
Receiving objects: 100% (5284773/5284773), 927.01 MiB | 993.00 KiB/s, done.
Resolving deltas: 100% (4438260/4438260), done.
Checking connectivity... done.
Checking out files: 100% (58023/58023), done.
~$ cd linux
~/linux$ patch -p1 < ../0001-Allow-user-probes-on-versioned-symbols.patch
patching file tools/perf/arch/powerpc/util/sym-handling.c
patching file tools/perf/util/map.c
patching file tools/perf/util/map.h
patching file tools/perf/util/symbol.c
patching file tools/perf/util/symbol.h
--

-- >8 --
Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores versioning for default symbols, thus allowing probes to be
created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke <p...@us.ibm.com>
---
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 61 +++--
 tools/perf/util/symbol.h| 11 ++
 5 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..bf9a2

Re: [PATCH v6] Allow user probes on versioned symbols

2017-04-25 Thread Paul Clarke

On 04/24/2017 11:34 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 13, 2017 at 12:03:13PM -0500, Paul Clarke escreveu:
>> v4:
>> - rebased to acme/perf/core
> 
> Are you sure?
> 
> [acme@jouet linux]$ patch -p1 < /wb/1.patch 
> patching file tools/perf/arch/powerpc/util/sym-handling.c
> Hunk #1 FAILED at 52.
> 1 out of 1 hunk FAILED -- saving rejects to file 
> tools/perf/arch/powerpc/util/sym-handling.c.rej
> patching file tools/perf/util/map.c
> Hunk #1 FAILED at 325.
> 1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/map.c.rej
> patching file tools/perf/util/map.h
> Hunk #1 FAILED at 130.
> 1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/map.h.rej
> patching file tools/perf/util/symbol.c
> Hunk #1 FAILED at 87.
> Hunk #2 FAILED at 396.
> Hunk #3 FAILED at 411.
> Hunk #4 FAILED at 424.
> Hunk #5 FAILED at 500.
> 5 out of 5 hunks FAILED -- saving rejects to file tools/perf/util/symbol.c.rej
> patching file tools/perf/util/symbol.h
> Hunk #1 FAILED at 348.
> 1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/symbol.h.rej
> [acme@jouet linux]$ 

Sigh. It worked for me, with some offsets.  It's very likely I'm doing 
something wrong, but I don't know what.  (Apologies, if so.)  I generated a new 
patch (with new offsets, attached), and it works here;
--
~$ git clone -b perf/core 
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Cloning into 'linux'...
remote: Counting objects: 5284773, done.
remote: Compressing objects: 100% (805895/805895), done.
remote: Total 5284773 (delta 4438260), reused 5284366 (delta 4437981)
Receiving objects: 100% (5284773/5284773), 927.01 MiB | 993.00 KiB/s, done.
Resolving deltas: 100% (4438260/4438260), done.
Checking connectivity... done.
Checking out files: 100% (58023/58023), done.
~$ cd linux
~/linux$ patch -p1 < ../0001-Allow-user-probes-on-versioned-symbols.patch
patching file tools/perf/arch/powerpc/util/sym-handling.c
patching file tools/perf/util/map.c
patching file tools/perf/util/map.h
patching file tools/perf/util/symbol.c
patching file tools/perf/util/symbol.h
--

-- >8 --
Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores versioning for default symbols, thus allowing probes to be
created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 61 +++--
 tools/perf/util/symbol.h| 11 ++
 5 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..bf9a259 100644
---

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

2017-04-21 Thread Paul Clarke

Sent too soon.  The suggestions don't guarantee null termination.  Refined, 
below. (Sorry for the noise.)

On 04/21/2017 08:33 AM, Paul Clarke wrote:
> On 04/21/2017 07:33 AM, Naveen N. Rao wrote:
>> Convert usage of strchr()/strncpy()/strncat() to
>> strnchr()/memcpy()/strlcat() for simpler and safer string manipulation.

>> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
>> index 97b5eed1f76d..c73fb6e3b43f 100644
>> --- a/arch/powerpc/kernel/kprobes.c
>> +++ b/arch/powerpc/kernel/kprobes.c
>> @@ -65,28 +65,27 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, 
>> unsigned int offset)
>>  char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];
>>  const char *modsym;
>>  bool dot_appended = false;
>> -if ((modsym = strchr(name, ':')) != NULL) {
>> +if ((modsym = strnchr(name, ':', MODULE_NAME_LEN)) != NULL) {
>>  modsym++;
>>  if (*modsym != '\0' && *modsym != '.') {
>>  /* Convert to  */
>> -strncpy(dot_name, name, modsym - name);
>> +memcpy(dot_name, name, modsym - name);
>>  dot_name[modsym - name] = '.';
>>  dot_name[modsym - name + 1] = '\0';
>> -strncat(dot_name, modsym,
>> -sizeof(dot_name) - (modsym - name) - 2);
>> +strlcat(dot_name, modsym, sizeof(dot_name));
> 
> Would it be more efficient here to replace this:
> --
> dot_name[modsym - name + 1] = '\0';
> strlcat(dot_name, modsym, sizeof(dot_name));
> --
> 
> with this:
> strncpy(_name[modsym - name + 1], modsym, KSYM_NAME_LEN);

keep the null termination, and just adjust the starting point for strlcat:
--
dot_name[modsym - name + 1] = '\0';
strlcat(_name[modsym - name + 1], modsym, KSYM_NAME_LEN);
--

> (So you aren't rescanning dot_name to find the end, when you already know the 
> end position?)
> 
>>  dot_appended = true;
>>  } else {
>>  dot_name[0] = '\0';
>> -strncat(dot_name, name, sizeof(dot_name) - 1);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(dot_name, name, sizeof(dot_name));
> 
> (and remove the null termination immediately above)

nevermind.  :-)

> 
>>  }
>>  } else if (name[0] != '.') {
>>  dot_name[0] = '.';
>>  dot_name[1] = '\0';
>> -strncat(dot_name, name, KSYM_NAME_LEN - 2);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(_name[1], name, sizeof(dot_name));
> 
> (and remove the null termination immediately above)
> 

nevermind.  :-)

>>  dot_appended = true;
>>  } else {
>>  dot_name[0] = '\0';
>> -strncat(dot_name, name, KSYM_NAME_LEN - 1);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(dot_name, name, sizeof(dot_name));
> 
> (and remove the null termination immediately above)
> 
>>  }

nevermind.  :-)

PC

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

2017-04-21 Thread Paul Clarke

Sent too soon.  The suggestions don't guarantee null termination.  Refined, 
below. (Sorry for the noise.)

On 04/21/2017 08:33 AM, Paul Clarke wrote:
> On 04/21/2017 07:33 AM, Naveen N. Rao wrote:
>> Convert usage of strchr()/strncpy()/strncat() to
>> strnchr()/memcpy()/strlcat() for simpler and safer string manipulation.

>> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
>> index 97b5eed1f76d..c73fb6e3b43f 100644
>> --- a/arch/powerpc/kernel/kprobes.c
>> +++ b/arch/powerpc/kernel/kprobes.c
>> @@ -65,28 +65,27 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, 
>> unsigned int offset)
>>  char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];
>>  const char *modsym;
>>  bool dot_appended = false;
>> -if ((modsym = strchr(name, ':')) != NULL) {
>> +if ((modsym = strnchr(name, ':', MODULE_NAME_LEN)) != NULL) {
>>  modsym++;
>>  if (*modsym != '\0' && *modsym != '.') {
>>  /* Convert to  */
>> -strncpy(dot_name, name, modsym - name);
>> +memcpy(dot_name, name, modsym - name);
>>  dot_name[modsym - name] = '.';
>>  dot_name[modsym - name + 1] = '\0';
>> -strncat(dot_name, modsym,
>> -sizeof(dot_name) - (modsym - name) - 2);
>> +strlcat(dot_name, modsym, sizeof(dot_name));
> 
> Would it be more efficient here to replace this:
> --
> dot_name[modsym - name + 1] = '\0';
> strlcat(dot_name, modsym, sizeof(dot_name));
> --
> 
> with this:
> strncpy(_name[modsym - name + 1], modsym, KSYM_NAME_LEN);

keep the null termination, and just adjust the starting point for strlcat:
--
dot_name[modsym - name + 1] = '\0';
strlcat(_name[modsym - name + 1], modsym, KSYM_NAME_LEN);
--

> (So you aren't rescanning dot_name to find the end, when you already know the 
> end position?)
> 
>>  dot_appended = true;
>>  } else {
>>  dot_name[0] = '\0';
>> -strncat(dot_name, name, sizeof(dot_name) - 1);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(dot_name, name, sizeof(dot_name));
> 
> (and remove the null termination immediately above)

nevermind.  :-)

> 
>>  }
>>  } else if (name[0] != '.') {
>>  dot_name[0] = '.';
>>  dot_name[1] = '\0';
>> -strncat(dot_name, name, KSYM_NAME_LEN - 2);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(_name[1], name, sizeof(dot_name));
> 
> (and remove the null termination immediately above)
> 

nevermind.  :-)

>>  dot_appended = true;
>>  } else {
>>  dot_name[0] = '\0';
>> -strncat(dot_name, name, KSYM_NAME_LEN - 1);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(dot_name, name, sizeof(dot_name));
> 
> (and remove the null termination immediately above)
> 
>>  }

nevermind.  :-)

PC

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

2017-04-21 Thread Paul Clarke

On 04/21/2017 08:33 AM, Paul Clarke wrote:
> On 04/21/2017 07:33 AM, Naveen N. Rao wrote:
>>  } else if (name[0] != '.') {
>>  dot_name[0] = '.';
>>  dot_name[1] = '\0';
>> -strncat(dot_name, name, KSYM_NAME_LEN - 2);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(_name[1], name, sizeof(dot_name));

oops.  s/sizeof(dot_name)/sizeof(dot_name) - 1/

PC

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

2017-04-21 Thread Paul Clarke

On 04/21/2017 08:33 AM, Paul Clarke wrote:
> On 04/21/2017 07:33 AM, Naveen N. Rao wrote:
>>  } else if (name[0] != '.') {
>>  dot_name[0] = '.';
>>  dot_name[1] = '\0';
>> -strncat(dot_name, name, KSYM_NAME_LEN - 2);
>> +strlcat(dot_name, name, sizeof(dot_name));
> 
> and here do:
> strncpy(_name[1], name, sizeof(dot_name));

oops.  s/sizeof(dot_name)/sizeof(dot_name) - 1/

PC

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

2017-04-21 Thread Paul Clarke

On 04/21/2017 07:33 AM, Naveen N. Rao wrote:
> Convert usage of strchr()/strncpy()/strncat() to
> strnchr()/memcpy()/strlcat() for simpler and safer string manipulation.
> 
> Reported-by: David Laight 
> Signed-off-by: Naveen N. Rao 
> ---
> Changes: Additionally convert the strchr().
> 
> 
>  arch/powerpc/kernel/kprobes.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 97b5eed1f76d..c73fb6e3b43f 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -65,28 +65,27 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, 
> unsigned int offset)
>   char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];
>   const char *modsym;
>   bool dot_appended = false;
> - if ((modsym = strchr(name, ':')) != NULL) {
> + if ((modsym = strnchr(name, ':', MODULE_NAME_LEN)) != NULL) {
>   modsym++;
>   if (*modsym != '\0' && *modsym != '.') {
>   /* Convert to  */
> - strncpy(dot_name, name, modsym - name);
> + memcpy(dot_name, name, modsym - name);
>   dot_name[modsym - name] = '.';
>   dot_name[modsym - name + 1] = '\0';
> - strncat(dot_name, modsym,
> - sizeof(dot_name) - (modsym - name) - 2);
> + strlcat(dot_name, modsym, sizeof(dot_name));

Would it be more efficient here to replace this:
--
dot_name[modsym - name + 1] = '\0';
strlcat(dot_name, modsym, sizeof(dot_name));
--

with this:
strncpy(_name[modsym - name + 1], modsym, KSYM_NAME_LEN);

(So you aren't rescanning dot_name to find the end, when you already know the 
end position?)

>   dot_appended = true;
>   } else {
>   dot_name[0] = '\0';
> - strncat(dot_name, name, sizeof(dot_name) - 1);
> + strlcat(dot_name, name, sizeof(dot_name));

and here do:
strncpy(dot_name, name, sizeof(dot_name));

(and remove the null termination immediately above)

>   }
>   } else if (name[0] != '.') {
>   dot_name[0] = '.';
>   dot_name[1] = '\0';
> - strncat(dot_name, name, KSYM_NAME_LEN - 2);
> + strlcat(dot_name, name, sizeof(dot_name));

and here do:
strncpy(_name[1], name, sizeof(dot_name));

(and remove the null termination immediately above)

>   dot_appended = true;
>   } else {
>   dot_name[0] = '\0';
> - strncat(dot_name, name, KSYM_NAME_LEN - 1);
> + strlcat(dot_name, name, sizeof(dot_name));

and here do:
strncpy(dot_name, name, sizeof(dot_name));

(and remove the null termination immediately above)

>   }

PC

Re: [PATCH v4 4/7] powerpc/kprobes: Use safer string functions in kprobe_lookup_name()

2017-04-21 Thread Paul Clarke

On 04/21/2017 07:33 AM, Naveen N. Rao wrote:
> Convert usage of strchr()/strncpy()/strncat() to
> strnchr()/memcpy()/strlcat() for simpler and safer string manipulation.
> 
> Reported-by: David Laight 
> Signed-off-by: Naveen N. Rao 
> ---
> Changes: Additionally convert the strchr().
> 
> 
>  arch/powerpc/kernel/kprobes.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 97b5eed1f76d..c73fb6e3b43f 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -65,28 +65,27 @@ kprobe_opcode_t *kprobe_lookup_name(const char *name, 
> unsigned int offset)
>   char dot_name[MODULE_NAME_LEN + 1 + KSYM_NAME_LEN];
>   const char *modsym;
>   bool dot_appended = false;
> - if ((modsym = strchr(name, ':')) != NULL) {
> + if ((modsym = strnchr(name, ':', MODULE_NAME_LEN)) != NULL) {
>   modsym++;
>   if (*modsym != '\0' && *modsym != '.') {
>   /* Convert to  */
> - strncpy(dot_name, name, modsym - name);
> + memcpy(dot_name, name, modsym - name);
>   dot_name[modsym - name] = '.';
>   dot_name[modsym - name + 1] = '\0';
> - strncat(dot_name, modsym,
> - sizeof(dot_name) - (modsym - name) - 2);
> + strlcat(dot_name, modsym, sizeof(dot_name));

Would it be more efficient here to replace this:
--
dot_name[modsym - name + 1] = '\0';
strlcat(dot_name, modsym, sizeof(dot_name));
--

with this:
strncpy(_name[modsym - name + 1], modsym, KSYM_NAME_LEN);

(So you aren't rescanning dot_name to find the end, when you already know the 
end position?)

>   dot_appended = true;
>   } else {
>   dot_name[0] = '\0';
> - strncat(dot_name, name, sizeof(dot_name) - 1);
> + strlcat(dot_name, name, sizeof(dot_name));

and here do:
strncpy(dot_name, name, sizeof(dot_name));

(and remove the null termination immediately above)

>   }
>   } else if (name[0] != '.') {
>   dot_name[0] = '.';
>   dot_name[1] = '\0';
> - strncat(dot_name, name, KSYM_NAME_LEN - 2);
> + strlcat(dot_name, name, sizeof(dot_name));

and here do:
strncpy(_name[1], name, sizeof(dot_name));

(and remove the null termination immediately above)

>   dot_appended = true;
>   } else {
>   dot_name[0] = '\0';
> - strncat(dot_name, name, KSYM_NAME_LEN - 1);
> + strlcat(dot_name, name, sizeof(dot_name));

and here do:
strncpy(dot_name, name, sizeof(dot_name));

(and remove the null termination immediately above)

>   }

PC

Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration

2017-04-21 Thread Paul Clarke

a nit or two, below...

On 04/21/2017 07:32 AM, Naveen N. Rao wrote:
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 6a128f3a7ed1..ff9b1ac72a38 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1383,6 +1383,34 @@ bool within_kprobe_blacklist(unsigned long addr)
>  }
> 
>  /*
> + * We mainly want to ensure that the provided string is of a reasonable 
> length
> + * and is of the form [:], so that this is safe to 
> process
> + * further.
> + * We don't worry about invalid characters as those will just prevent
> + * matching existing kallsyms.
> + */
> +bool is_valid_kprobe_symbol_name(const char *name)
> +{
> + size_t sym_len;
> + const char *s;
> +
> + s = strnchr(name, ':', MODULE_NAME_LEN + KSYM_NAME_LEN + 1);
> + if (s) {
> + sym_len = (size_t)(s - name);
> + if (sym_len <= 0  || sym_len >= MODULE_NAME_LEN)

"sym_len <= 0" looks odd here, since sym_len is likely unsigned and would never 
be less than zero, anyway.

> + return false;
> + s++;
> + } else
> + s = name;
> +
> + sym_len = strnlen(s, KSYM_NAME_LEN);
> + if (sym_len <= 0 || sym_len >= KSYM_NAME_LEN)

here, too.

> + return false;
> +
> + return true;
> +}

PC

Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration

2017-04-21 Thread Paul Clarke

a nit or two, below...

On 04/21/2017 07:32 AM, Naveen N. Rao wrote:
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 6a128f3a7ed1..ff9b1ac72a38 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1383,6 +1383,34 @@ bool within_kprobe_blacklist(unsigned long addr)
>  }
> 
>  /*
> + * We mainly want to ensure that the provided string is of a reasonable 
> length
> + * and is of the form [:], so that this is safe to 
> process
> + * further.
> + * We don't worry about invalid characters as those will just prevent
> + * matching existing kallsyms.
> + */
> +bool is_valid_kprobe_symbol_name(const char *name)
> +{
> + size_t sym_len;
> + const char *s;
> +
> + s = strnchr(name, ':', MODULE_NAME_LEN + KSYM_NAME_LEN + 1);
> + if (s) {
> + sym_len = (size_t)(s - name);
> + if (sym_len <= 0  || sym_len >= MODULE_NAME_LEN)

"sym_len <= 0" looks odd here, since sym_len is likely unsigned and would never 
be less than zero, anyway.

> + return false;
> + s++;
> + } else
> + s = name;
> +
> + sym_len = strnlen(s, KSYM_NAME_LEN);
> + if (sym_len <= 0 || sym_len >= KSYM_NAME_LEN)

here, too.

> + return false;
> +
> + return true;
> +}

PC

Re: [PATCH v6] Allow user probes on versioned symbols

2017-04-20 Thread Paul Clarke

ping

On 04/13/2017 12:03 PM, Paul Clarke wrote:
> Symbol versioning, as in glibc, results in symbols being defined as:
> @[@]
> (Note that "@@" identifies a default symbol, if the symbol name
> is repeated.)
> 
> perf is currently unable to deal with this, and is unable to create
> user probes at such symbols:
> --
> $ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
> 8d30 t __pthread_create_2_1
> 8d30 T pthread_create@@GLIBC_2.17
> $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
> pthread_create
> probe-definition(0): pthread_create
> symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Open Debuginfo file: 
> /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
> Try to find probe point from debuginfo.
> Probe point 'pthread_create' not found.
> Error: Failed to add events. Reason: No such file or directory (Code: -2)
> --
> 
> One is not able to specify the fully versioned symbol, either, due to
> syntactic conflicts with other uses of "@" by perf:
> --
> $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
> pthread_create@@GLIBC_2.17
> probe-definition(0): pthread_create@@GLIBC_2.17
> Semantic error :SRC@SRC is not allowed.
> 0 arguments
> Error: Command Parse Error. Reason: Invalid argument (Code: -22)
> --
> 
> This patch ignores versioning for default symbols, thus allowing probes to be
> created for these symbols:
> --
> $ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
> pthread_create
> Added new event:
> probe_libpthread:pthread_create (on pthread_create in 
> /lib/powerpc64le-linux-gnu/libpthread-2.19.so)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe_libpthread:pthread_create -aR sleep 1
> 
> $ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
> $ /usr/bin/sudo ./perf script
>   test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
> (3fff99248d38)
>   test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
> (3fff99248d38)
> $ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
> Removed event: probe_libpthread:pthread_create
> --
> 
> Signed-off-by: Paul A. Clarke <p...@us.ibm.com>
> ---
> v6:
> - new name for enum (per Masami Hiramatsu)
> - fixed use of "unsigned int" instead of enum
> - some whitespace adjustments
> 
> v5:
> - now using new enum to specify matching semantics (per Masami Hiramatsu)
> 
> v4:
> - rebased to acme/perf/core
> - moved changes from "map" namespace to "symbol" namespace,
> - rewrote symbol__compare (now *match) to avoid need for strdup
> - new symbol__match_symbol_name to support versioned symbols, ignoring default
>  tags
> - new arch__compare_symbol_names_n to map to strncmp
> - dso__find_symbol_by_name: now tries exact match (as before), then tries
>   also adding symbols tagged as default (@@)
> - symbols__find_by_name: new parameter to support finding with or without 
> default
>  tags
> - does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)
> 
> v3:
> - code style fixes per David Ahern
> 
> v2:
> - move logic from arch__compare_symbol_names to new map__compare_symbol_names
> - call through from map__compare_symbol_names to arch__compare_symbol_names
> - redirect uses of arch__compare_symbol_names
> - send patch to LKML
>   tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
>   tools/perf/util/map.c   |  5 ---
>   tools/perf/util/map.h   |  5 ++-
>   tools/perf/util/symbol.c| 61 
> +++--
>   tools/perf/util/symbol.h| 11 ++
>   5 files changed, 74 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
> b/tools/perf/arch/powerpc/util/sym-handling.c
> index 39dbe51..bf9a259 100644
> --- a/tools/perf/arch/powerpc/util/sym-handling.c
> +++ b/tools/perf/arch/powerpc/util/sym-handling.c
> @@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const 
> char *nameb)
>   
>   return strcmp(namea, nameb);
>   }
> +
> +int arch__compare_symbol_names_n(const char *namea, const char *nameb,
> +  unsigned int n)
> +{
> + /* Skip over initial dot */
> + if (*namea == '.')
> + namea++;
> +

Re: [PATCH v6] Allow user probes on versioned symbols

2017-04-20 Thread Paul Clarke

ping

On 04/13/2017 12:03 PM, Paul Clarke wrote:
> Symbol versioning, as in glibc, results in symbols being defined as:
> @[@]
> (Note that "@@" identifies a default symbol, if the symbol name
> is repeated.)
> 
> perf is currently unable to deal with this, and is unable to create
> user probes at such symbols:
> --
> $ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
> 8d30 t __pthread_create_2_1
> 8d30 T pthread_create@@GLIBC_2.17
> $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
> pthread_create
> probe-definition(0): pthread_create
> symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Open Debuginfo file: 
> /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
> Try to find probe point from debuginfo.
> Probe point 'pthread_create' not found.
> Error: Failed to add events. Reason: No such file or directory (Code: -2)
> --
> 
> One is not able to specify the fully versioned symbol, either, due to
> syntactic conflicts with other uses of "@" by perf:
> --
> $ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
> pthread_create@@GLIBC_2.17
> probe-definition(0): pthread_create@@GLIBC_2.17
> Semantic error :SRC@SRC is not allowed.
> 0 arguments
> Error: Command Parse Error. Reason: Invalid argument (Code: -22)
> --
> 
> This patch ignores versioning for default symbols, thus allowing probes to be
> created for these symbols:
> --
> $ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
> pthread_create
> Added new event:
> probe_libpthread:pthread_create (on pthread_create in 
> /lib/powerpc64le-linux-gnu/libpthread-2.19.so)
> 
> You can now use it in all perf tools, such as:
> 
>   perf record -e probe_libpthread:pthread_create -aR sleep 1
> 
> $ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
> $ /usr/bin/sudo ./perf script
>   test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
> (3fff99248d38)
>   test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
> (3fff99248d38)
> $ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
> Removed event: probe_libpthread:pthread_create
> --
> 
> Signed-off-by: Paul A. Clarke 
> ---
> v6:
> - new name for enum (per Masami Hiramatsu)
> - fixed use of "unsigned int" instead of enum
> - some whitespace adjustments
> 
> v5:
> - now using new enum to specify matching semantics (per Masami Hiramatsu)
> 
> v4:
> - rebased to acme/perf/core
> - moved changes from "map" namespace to "symbol" namespace,
> - rewrote symbol__compare (now *match) to avoid need for strdup
> - new symbol__match_symbol_name to support versioned symbols, ignoring default
>  tags
> - new arch__compare_symbol_names_n to map to strncmp
> - dso__find_symbol_by_name: now tries exact match (as before), then tries
>   also adding symbols tagged as default (@@)
> - symbols__find_by_name: new parameter to support finding with or without 
> default
>  tags
> - does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)
> 
> v3:
> - code style fixes per David Ahern
> 
> v2:
> - move logic from arch__compare_symbol_names to new map__compare_symbol_names
> - call through from map__compare_symbol_names to arch__compare_symbol_names
> - redirect uses of arch__compare_symbol_names
> - send patch to LKML
>   tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
>   tools/perf/util/map.c   |  5 ---
>   tools/perf/util/map.h   |  5 ++-
>   tools/perf/util/symbol.c| 61 
> +++--
>   tools/perf/util/symbol.h| 11 ++
>   5 files changed, 74 insertions(+), 20 deletions(-)
> 
> diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
> b/tools/perf/arch/powerpc/util/sym-handling.c
> index 39dbe51..bf9a259 100644
> --- a/tools/perf/arch/powerpc/util/sym-handling.c
> +++ b/tools/perf/arch/powerpc/util/sym-handling.c
> @@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const 
> char *nameb)
>   
>   return strcmp(namea, nameb);
>   }
> +
> +int arch__compare_symbol_names_n(const char *namea, const char *nameb,
> +  unsigned int n)
> +{
> + /* Skip over initial dot */
> + if (*namea == '.')
> + namea++;
> + if (*nameb == '.')
> + nam

[PATCH v6] Allow user probes on versioned symbols

2017-04-13 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores versioning for default symbols, thus allowing probes to be
created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v6:
- new name for enum (per Masami Hiramatsu)
- fixed use of "unsigned int" instead of enum
- some whitespace adjustments

v5:
- now using new enum to specify matching semantics (per Masami Hiramatsu)

v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
 also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 61 +++--
 tools/perf/util/symbol.h| 11 ++
 5 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..bf9a259 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
 	return strcmp(namea, nameb);

 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)

-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..f9e8ac8 100644
--- a/tools/perf/util/map.h
+++

[PATCH v6] Allow user probes on versioned symbols

2017-04-13 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores versioning for default symbols, thus allowing probes to be
created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v6:
- new name for enum (per Masami Hiramatsu)
- fixed use of "unsigned int" instead of enum
- some whitespace adjustments

v5:
- now using new enum to specify matching semantics (per Masami Hiramatsu)

v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
 also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 61 +++--
 tools/perf/util/symbol.h| 11 ++
 5 files changed, 74 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..bf9a259 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
 	return strcmp(namea, nameb);

 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)

-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..f9e8ac8 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13

Re: [PATCH v5] Allow user probes on versioned symbols.

2017-04-13 Thread Paul Clarke


On 04/12/2017 09:20 PM, Masami Hiramatsu wrote:

On Wed, 12 Apr 2017 09:41:51 -0500
Paul Clarke <p...@us.ibm.com> wrote:

  static struct symbol *symbols__find_by_name(struct rb_root *symbols,
-   const char *name)
+   const char *name,
+   unsigned int includes)


Here, you might miss replacing this 'unsigned int' with enum.
(actually, enum is equal to int, not unsigned int)


(Ugh.) My bad. Will fix.


+enum symbols_tag_includes {
+   SYMBOLS_TAG__INCLUDE_NONE,
+   SYMBOLS_TAG__INCLUDE_DEFAULT_ONLY
+};


BTW, would we need such 's' for plural and third person singular for type name?
And also, you should use enum type name for prefix so that other developers
easily find the definition of enumeration, e.g.

enum symbol_tag_include {
SYMBOL_TAG_INCLUDE__NONE = 0,
SYMBOL_TAG_INCLUDE__DEFAULT_ONLY
};


I was thinking the top-level namespace would be "symbols", because we are not necessarily working with a 
single symbol.  Secondary namespace would be "tag", since this enum is very specific to tags.  Then, the 
actions are whether to "include none (of tagged symbols)" or "include only symbols tagged as 
default".

I'm fine with your suggestion, though, and will submit a new patch 
incorporating that soon.

Regards,
PC

Re: [PATCH v5] Allow user probes on versioned symbols.

2017-04-13 Thread Paul Clarke


On 04/12/2017 09:20 PM, Masami Hiramatsu wrote:

On Wed, 12 Apr 2017 09:41:51 -0500
Paul Clarke  wrote:

  static struct symbol *symbols__find_by_name(struct rb_root *symbols,
-   const char *name)
+   const char *name,
+   unsigned int includes)


Here, you might miss replacing this 'unsigned int' with enum.
(actually, enum is equal to int, not unsigned int)


(Ugh.) My bad. Will fix.


+enum symbols_tag_includes {
+   SYMBOLS_TAG__INCLUDE_NONE,
+   SYMBOLS_TAG__INCLUDE_DEFAULT_ONLY
+};


BTW, would we need such 's' for plural and third person singular for type name?
And also, you should use enum type name for prefix so that other developers
easily find the definition of enumeration, e.g.

enum symbol_tag_include {
SYMBOL_TAG_INCLUDE__NONE = 0,
SYMBOL_TAG_INCLUDE__DEFAULT_ONLY
};


I was thinking the top-level namespace would be "symbols", because we are not necessarily working with a 
single symbol.  Secondary namespace would be "tag", since this enum is very specific to tags.  Then, the 
actions are whether to "include none (of tagged symbols)" or "include only symbols tagged as 
default".

I'm fine with your suggestion, though, and will submit a new patch 
incorporating that soon.

Regards,
PC

[PATCH v5] Allow user probes on versioned symbols.

2017-04-12 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores versioning for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v5:
- now using new enum to specify matching semantics (per Masami Hiramatsu)

v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
   tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
   tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML

 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 62 +++--
 tools/perf/util/symbol.h| 11 +
 5 files changed, 75 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..0d40e17 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
 	return strcmp(namea, nameb);

 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)

-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..04b7238 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
  */
 #define __map__for_each_symbol_by_name(map, sym_name, pos) \
for (pos =

[PATCH v5] Allow user probes on versioned symbols.

2017-04-12 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores versioning for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v5:
- now using new enum to specify matching semantics (per Masami Hiramatsu)

v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
   tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
   tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML

 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 62 +++--
 tools/perf/util/symbol.h| 11 +
 5 files changed, 75 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..0d40e17 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
 	return strcmp(namea, nameb);

 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)

-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..04b7238 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
  */
 #define __map__for_each_symbol_by_name(map, sym_name, pos) \
for (pos = map__find_symbol_by_name(map,

Re: [PATCH v4] tools/perf: Allow user probes on versioned symbols

2017-04-10 Thread Paul Clarke


On 04/10/2017 08:11 AM, Masami Hiramatsu wrote:

On Wed, 5 Apr 2017 22:30:03 -0500
Paul Clarke <p...@us.ibm.com> wrote:

Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores the versioning tag for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

  perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
  test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
  test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke <p...@us.ibm.com>
---
v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
   tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
   tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
  tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
  tools/perf/util/map.c   |  5 ---
  tools/perf/util/map.h   |  5 ++-
  tools/perf/util/symbol.c| 62 +++--
  tools/perf/util/symbol.h|  9 +
  5 files changed, 73 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..0d40e17 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)

return strcmp(namea, nameb);
  }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
  #endif

  #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
  }

-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
-{
-   return strcmp(namea, nameb);
-}
-
  struct symbol *map__find_symbol(struct map *map, u64 addr)
  {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..325bbc8 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/

Re: [PATCH v4] tools/perf: Allow user probes on versioned symbols

2017-04-10 Thread Paul Clarke


On 04/10/2017 08:11 AM, Masami Hiramatsu wrote:

On Wed, 5 Apr 2017 22:30:03 -0500
Paul Clarke  wrote:

Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores the versioning tag for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

  perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
  test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
  test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
   tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
   tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
  tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
  tools/perf/util/map.c   |  5 ---
  tools/perf/util/map.h   |  5 ++-
  tools/perf/util/symbol.c| 62 +++--
  tools/perf/util/symbol.h|  9 +
  5 files changed, 73 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..0d40e17 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)

return strcmp(namea, nameb);
  }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
  #endif

  #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
  }

-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
-{
-   return strcmp(namea, nameb);
-}
-
  struct symbol *map__find_symbol(struct map *map, u64 addr)
  {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..325bbc8 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
   */
  #defin

Re: [PATCH v4] tools/perf: Allow user probes on versioned symbols

2017-04-06 Thread Paul Clarke


On 04/06/2017 09:36 AM, Arnaldo Carvalho de Melo wrote:

Em Wed, Apr 05, 2017 at 10:30:03PM -0500, Paul Clarke escreveu:

Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores the versioning tag for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke <p...@us.ibm.com>
---
v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
  tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
   also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
  tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 62 +++--
 tools/perf/util/symbol.h|  9 +
 5 files changed, 73 insertions(+), 20 deletions(-)

[...]

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 9b4d8ba..c29440d 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -87,6 +87,17 @@ static int prefix_underscores_count(const char *str)
return tail - str;
 }
+int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
+{
+   return strcmp(namea, nameb);
+}
+
+int __weak arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   return strncmp(namea, nameb, n);
+}
+
 int __weak arch__choose_best_symbol(struct symbol *syma,
struct symbol *symb __maybe_unused)
 {
@@ -396,8 +407,26 @@ static void symbols__sort_by_name(struct rb_root *symbols,
}
 }
+int symbol__match_symbol_name(const char *name, const char *str,
+   int including_tags)
+{
+   const char *versioning;
+
+   if (including_tags == SYMBOLS__TAG_INCLUDE_DEFAULT_ONLY &&
+   (versioning = strstr(name,"@@"))) {
+
+   unsigned int len = strlen(str);
+   if (len < versioning - name)
+   len = versioning - name;
+
+   return arch__compare_symbol_names_n(name, str, len);
+   } else
+   retur

Re: [PATCH v4] tools/perf: Allow user probes on versioned symbols

2017-04-06 Thread Paul Clarke


On 04/06/2017 09:36 AM, Arnaldo Carvalho de Melo wrote:

Em Wed, Apr 05, 2017 at 10:30:03PM -0500, Paul Clarke escreveu:

Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores the versioning tag for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
  tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
   also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
  tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 62 +++--
 tools/perf/util/symbol.h|  9 +
 5 files changed, 73 insertions(+), 20 deletions(-)

[...]

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 9b4d8ba..c29440d 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -87,6 +87,17 @@ static int prefix_underscores_count(const char *str)
return tail - str;
 }
+int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
+{
+   return strcmp(namea, nameb);
+}
+
+int __weak arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   return strncmp(namea, nameb, n);
+}
+
 int __weak arch__choose_best_symbol(struct symbol *syma,
struct symbol *symb __maybe_unused)
 {
@@ -396,8 +407,26 @@ static void symbols__sort_by_name(struct rb_root *symbols,
}
 }
+int symbol__match_symbol_name(const char *name, const char *str,
+   int including_tags)
+{
+   const char *versioning;
+
+   if (including_tags == SYMBOLS__TAG_INCLUDE_DEFAULT_ONLY &&
+   (versioning = strstr(name,"@@"))) {
+
+   unsigned int len = strlen(str);
+   if (len < versioning - name)
+   len = versioning - name;
+
+   return arch__compare_symbol_names_n(name, str, len);
+   } else
+   return arch__compare_symbol_names(name, str);
+}

Re: [PATCH v3] Allow user probes on versioned symbols

2017-04-05 Thread Paul Clarke

On 04/04/2017 09:26 AM, Arnaldo Carvalho de Melo wrote:

Em Tue, Apr 04, 2017 at 11:18:02PM +0900, Masami Hiramatsu escreveu:

On Mon, 3 Apr 2017 11:46:58 -0300
Arnaldo Carvalho de Melo  wrote:
> > > But apart from those problems, I think that one should be able to ask
> > > for a versioned symbol, to probe just apps using that specific version,
>
> > I agree, but wasn't trying to tackle that at the moment.  I can look into 
it, though.
>
> > > for instance, we should consider the whole name as two functions, which
> > > in fact, they are, no?
>
> > I'm not sure I understand what you mean here.  Do you mean we should set a 
probe at every version of a given symbol name?  For example, if there are symbols:
> > a@@V2
> > a@V1.1
> > a@V1
>
> > ...for a request to set a probe at "a", we'd actually set a probe at all 3?
>
> I think that we should just probe the default for that symbol and have a
> way to probe all of them, perhaps using the wildcard, i.e.:
>
> [root@jouet linux]# nm /lib64/libpthread-2.24.so  | grep ' 
pthread_cond_timedwait'
> dd90 T pthread_cond_timedwait@GLIBC_2.2.5
> d6e0 T pthread_cond_timedwait@@GLIBC_2.3.2
> [root@jouet linux]#
>
>   # perf probe -x /lib64/libpthread-2.24.so pthread_cond_timedwait
>
> should be equivalent to:
>
>   # perf probe -x /lib64/libpthread-2.24.so 
pthread_cond_timedwait@@GLIBC_2.3.2
>
> Which matches how these versioned symbols are resolved by the linker,
> no?
>
> I.e. when 'pthread_cond_timedwait' is specified and the symbol table
> lookup fails, I think we should re-lookup for
> 'pthread_cond_timedwait@@*', i.e. we should have a
> symbol__find_default_by_name(), which will take the
> "pthread_cond_timedwait" and use a symbol comparison using
> strncmp(strlen(key)), matching, should then look at right after the
> common part looking for the double @@.

Hm, this 'fallback'process sounds good idea to me.

I just sent a patch that does what you suggest, above.  To avoid duplicating 
the code in symbols_find_by_name, I added a parameter to tell it whether to 
ignore default symbol tags or not.

This is just trying to keep the semantics used by the original user of
this syntax, i.e. the linker.

BTW, how would we support other SYMBOL@VERSION, since we already
use '@' for specifying source code?
One possible way is to support it directly in perf-probe. If it
failed to find probe point from dwarf, try to find from symbol
map by using '@VERSION' suffix.

Right, we would be overloading that @ symbol, since version numbers
usually are very different of file source names :-)

There's not a lot of syntactic difference between "file" and "tag".  I don't think there 
is any standard for what either can be.  One might expect a "file" to be name.extension, where 
extension is a finite set (possibly fairly large).  A tag can be almost anything, I think.  One might expect 
it to end with a number.  I don't think there's a guarantee of either case, though.

It would seem one way to determine whether it's a file or a tag is to try to 
find it in the symbol tables.  If it's not there, assume it's a file.  (Or 
vice-versa.)

PC

Re: [PATCH v3] Allow user probes on versioned symbols

2017-04-05 Thread Paul Clarke

On 04/04/2017 09:26 AM, Arnaldo Carvalho de Melo wrote:

Em Tue, Apr 04, 2017 at 11:18:02PM +0900, Masami Hiramatsu escreveu:

On Mon, 3 Apr 2017 11:46:58 -0300
Arnaldo Carvalho de Melo  wrote:
> > > But apart from those problems, I think that one should be able to ask
> > > for a versioned symbol, to probe just apps using that specific version,
>
> > I agree, but wasn't trying to tackle that at the moment.  I can look into 
it, though.
>
> > > for instance, we should consider the whole name as two functions, which
> > > in fact, they are, no?
>
> > I'm not sure I understand what you mean here.  Do you mean we should set a 
probe at every version of a given symbol name?  For example, if there are symbols:
> > a@@V2
> > a@V1.1
> > a@V1
>
> > ...for a request to set a probe at "a", we'd actually set a probe at all 3?
>
> I think that we should just probe the default for that symbol and have a
> way to probe all of them, perhaps using the wildcard, i.e.:
>
> [root@jouet linux]# nm /lib64/libpthread-2.24.so  | grep ' 
pthread_cond_timedwait'
> dd90 T pthread_cond_timedwait@GLIBC_2.2.5
> d6e0 T pthread_cond_timedwait@@GLIBC_2.3.2
> [root@jouet linux]#
>
>   # perf probe -x /lib64/libpthread-2.24.so pthread_cond_timedwait
>
> should be equivalent to:
>
>   # perf probe -x /lib64/libpthread-2.24.so 
pthread_cond_timedwait@@GLIBC_2.3.2
>
> Which matches how these versioned symbols are resolved by the linker,
> no?
>
> I.e. when 'pthread_cond_timedwait' is specified and the symbol table
> lookup fails, I think we should re-lookup for
> 'pthread_cond_timedwait@@*', i.e. we should have a
> symbol__find_default_by_name(), which will take the
> "pthread_cond_timedwait" and use a symbol comparison using
> strncmp(strlen(key)), matching, should then look at right after the
> common part looking for the double @@.

Hm, this 'fallback'process sounds good idea to me.

I just sent a patch that does what you suggest, above.  To avoid duplicating 
the code in symbols_find_by_name, I added a parameter to tell it whether to 
ignore default symbol tags or not.

This is just trying to keep the semantics used by the original user of
this syntax, i.e. the linker.

BTW, how would we support other SYMBOL@VERSION, since we already
use '@' for specifying source code?
One possible way is to support it directly in perf-probe. If it
failed to find probe point from dwarf, try to find from symbol
map by using '@VERSION' suffix.

Right, we would be overloading that @ symbol, since version numbers
usually are very different of file source names :-)

There's not a lot of syntactic difference between "file" and "tag".  I don't think there 
is any standard for what either can be.  One might expect a "file" to be name.extension, where 
extension is a finite set (possibly fairly large).  A tag can be almost anything, I think.  One might expect 
it to end with a number.  I don't think there's a guarantee of either case, though.

It would seem one way to determine whether it's a file or a tag is to try to 
find it in the symbol tables.  If it's not there, assume it's a file.  (Or 
vice-versa.)

PC

[PATCH v4] tools/perf: Allow user probes on versioned symbols

2017-04-05 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores the versioning tag for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
  tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
   also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
  tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 62 +++--
 tools/perf/util/symbol.h|  9 +
 5 files changed, 73 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..0d40e17 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
 	return strcmp(namea, nameb);

 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)

-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..325bbc8 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
  */
 #define __map__for_each_symbol_by_name(map, sym_name, pos) \
for (pos = map__find_symbol_by_name(map, sym_name); \
-pos &&

[PATCH v4] tools/perf: Allow user probes on versioned symbols

2017-04-05 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

This patch ignores the versioning tag for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v4:
- rebased to acme/perf/core
- moved changes from "map" namespace to "symbol" namespace,
- rewrote symbol__compare (now *match) to avoid need for strdup
- new symbol__match_symbol_name to support versioned symbols, ignoring default
  tags
- new arch__compare_symbol_names_n to map to strncmp
- dso__find_symbol_by_name: now tries exact match (as before), then tries
   also adding symbols tagged as default (@@)
- symbols__find_by_name: new parameter to support finding with or without 
default
  tags
- does NOT handle setting probes using the tagged symbol name (symbol@[@]tag)

v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML
 tools/perf/arch/powerpc/util/sym-handling.c | 12 ++
 tools/perf/util/map.c   |  5 ---
 tools/perf/util/map.h   |  5 ++-
 tools/perf/util/symbol.c| 62 +++--
 tools/perf/util/symbol.h|  9 +
 5 files changed, 73 insertions(+), 20 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 39dbe51..0d40e17 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -52,6 +52,18 @@ int arch__compare_symbol_names(const char *namea, const char 
*nameb)
 
 	return strcmp(namea, nameb);

 }
+
+int arch__compare_symbol_names_n(const char *namea, const char *nameb,
+   unsigned int n)
+{
+   /* Skip over initial dot */
+   if (*namea == '.')
+   namea++;
+   if (*nameb == '.')
+   nameb++;
+
+   return strncmp(namea, nameb, n);
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index c1870ac..f4d8272 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -325,11 +325,6 @@ int map__load(struct map *map)
return 0;
 }
 
-int __weak arch__compare_symbol_names(const char *namea, const char *nameb)

-{
-   return strcmp(namea, nameb);
-}
-
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index c8a5a64..325bbc8 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
  */
 #define __map__for_each_symbol_by_name(map, sym_name, pos) \
for (pos = map__find_symbol_by_name(map, sym_name); \
-pos && arch__compare_symbol_names(pos->name,

Re: [PATCH v3] Allow user probes on versioned symbols

2017-03-31 Thread Paul Clarke


On 03/31/2017 12:31 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Mar 31, 2017 at 11:06:16AM -0500, Paul Clarke escreveu:

Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:


On top of what tree/branch should I try to apply this?


I worked from torvalds/linux.


Trying on acme/perf/core:


Pardon my ignorance, but where can I find that tree?


[acme@jouet linux]$ patch -p1 < /wb/1.patch
patching file tools/perf/util/auxtrace.c
Hunk #1 FAILED at 1875.

[...]


Apart from that, you are not checking the return of strndup, that
however unlikely, can fail, so must be checked.


It's in the middle of strcmp-type function, so all return values are valid.  
Shall I emit a message and call exit()?


On the style front you sometimes add a space after commas, sometimes
not, please make sure you add one.


Ack.


But apart from those problems, I think that one should be able to ask
for a versioned symbol, to probe just apps using that specific version,


I agree, but wasn't trying to tackle that at the moment.  I can look into it, 
though.


for instance, we should consider the whole name as two functions, which
in fact, they are, no?


I'm not sure I understand what you mean here.  Do you mean we should set a 
probe at every version of a given symbol name?  For example, if there are 
symbols:
a@@V2
a@V1.1
a@V1

...for a request to set a probe at "a", we'd actually set a probe at all 3?


Additionaly, I can't reproduce your problem here, on x86_64:


I just cloned from acme/linux, and will rebase to there, if that's the best 
tree.

PC

Re: [PATCH v3] Allow user probes on versioned symbols

2017-03-31 Thread Paul Clarke


On 03/31/2017 12:31 PM, Arnaldo Carvalho de Melo wrote:

Em Fri, Mar 31, 2017 at 11:06:16AM -0500, Paul Clarke escreveu:

Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:


On top of what tree/branch should I try to apply this?


I worked from torvalds/linux.


Trying on acme/perf/core:


Pardon my ignorance, but where can I find that tree?


[acme@jouet linux]$ patch -p1 < /wb/1.patch
patching file tools/perf/util/auxtrace.c
Hunk #1 FAILED at 1875.

[...]


Apart from that, you are not checking the return of strndup, that
however unlikely, can fail, so must be checked.


It's in the middle of strcmp-type function, so all return values are valid.  
Shall I emit a message and call exit()?


On the style front you sometimes add a space after commas, sometimes
not, please make sure you add one.


Ack.


But apart from those problems, I think that one should be able to ask
for a versioned symbol, to probe just apps using that specific version,


I agree, but wasn't trying to tackle that at the moment.  I can look into it, 
though.


for instance, we should consider the whole name as two functions, which
in fact, they are, no?


I'm not sure I understand what you mean here.  Do you mean we should set a 
probe at every version of a given symbol name?  For example, if there are 
symbols:
a@@V2
a@V1.1
a@V1

...for a request to set a probe at "a", we'd actually set a probe at all 3?


Additionaly, I can't reproduce your problem here, on x86_64:


I just cloned from acme/linux, and will rebase to there, if that's the best 
tree.

PC

[PATCH v3] Allow user probes on versioned symbols

2017-03-31 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

The attached patch ignores versioning for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML

 tools/perf/util/auxtrace.c |  2 +-
 tools/perf/util/map.c  | 23 +++
 tools/perf/util/map.h  |  3 ++-
 tools/perf/util/symbol.c   |  4 ++--
 4 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index c5a6e0b1..f3511a6 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -1875,7 +1875,7 @@ static bool dso_sym_match(struct symbol *sym, const char 
*name, int *cnt,
  int idx)
 {
/* Same name, and global or the n'th found or any */
-   return !arch__compare_symbol_names(name, sym->name) &&
+   return !map__compare_symbol_names(name, sym->name) &&
   ((!idx && sym->binding == STB_GLOBAL) ||
(idx > 0 && ++*cnt == idx) ||
idx < 0);
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 4f9a71c..26a3e87 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -330,6 +330,29 @@ int __weak arch__compare_symbol_names(const char *namea, 
const char *nameb)
return strcmp(namea, nameb);
 }
 
+int map__compare_symbol_names(const char *namea, const char *nameb)

+{
+   int rc;
+   const char *namea_versioning, *nameb_versioning;
+
+   namea_versioning = strstr(namea,"@@");
+   if (namea_versioning)
+   namea = strndup(namea,namea_versioning-namea);
+
+   nameb_versioning = strstr(nameb,"@@");
+   if (nameb_versioning)
+   nameb = strndup(nameb,nameb_versioning-nameb);
+
+   rc = arch__compare_symbol_names(namea, nameb);
+
+   if (namea_versioning)
+   free((void *)namea);
+   if (nameb_versioning)
+   free((void *)nameb);
+
+   return rc;
+}
+
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index abdacf8..aaad64d 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
  */
 #define __map__for_each_symbol_by_name(map, sym_name, pos) \
for (pos = map__find_symbol_by_name(map, sym_name); \
-pos && arch__compare_symbol_names(pos->name, sym_name) == 0;\
+pos && map__compare_symbol_names(pos->name, sym_name) == 0; \
 pos = symbol__next_by_name(pos))
 
 #define map__for_each_symbol_by_name(map, sym_name,

[PATCH v3] Allow user probes on versioned symbols

2017-03-31 Thread Paul Clarke


Symbol versioning, as in glibc, results in symbols being defined as:
@[@]
(Note that "@@" identifies a default symbol, if the symbol name
is repeated.)

perf is currently unable to deal with this, and is unable to create
user probes at such symbols:
--
$ nm /lib/powerpc64le-linux-gnu/libpthread.so.0 | grep pthread_create
8d30 t __pthread_create_2_1
8d30 T pthread_create@@GLIBC_2.17
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
probe-definition(0): pthread_create
symbol:pthread_create file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Open Debuginfo file: /usr/lib/debug/lib/powerpc64le-linux-gnu/libpthread-2.19.so
Try to find probe point from debuginfo.
Probe point 'pthread_create' not found.
   Error: Failed to add events. Reason: No such file or directory (Code: -2)
--

One is not able to specify the fully versioned symbol, either, due to
syntactic conflicts with other uses of "@" by perf:
--
$ /usr/bin/sudo perf probe -v -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create@@GLIBC_2.17
probe-definition(0): pthread_create@@GLIBC_2.17
Semantic error :SRC@SRC is not allowed.
0 arguments
   Error: Command Parse Error. Reason: Invalid argument (Code: -22)
--

The attached patch ignores versioning for default symbols, thus
allowing probes to be created for these symbols:
--
$ /usr/bin/sudo ./perf probe -x /lib/powerpc64le-linux-gnu/libpthread.so.0 
pthread_create
Added new event:
   probe_libpthread:pthread_create (on pthread_create in 
/lib/powerpc64le-linux-gnu/libpthread-2.19.so)

You can now use it in all perf tools, such as:

 perf record -e probe_libpthread:pthread_create -aR sleep 1

$ /usr/bin/sudo ./perf record -e probe_libpthread:pthread_create -aR ./test 2
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.052 MB perf.data (2 samples) ]
$ /usr/bin/sudo ./perf script
 test  2915 [000] 19124.260729: probe_libpthread:pthread_create: 
(3fff99248d38)
 test  2916 [000] 19124.260962: probe_libpthread:pthread_create: 
(3fff99248d38)
$ /usr/bin/sudo ./perf probe --del=probe_libpthread:pthread_create
Removed event: probe_libpthread:pthread_create
--

Signed-off-by: Paul A. Clarke 
---
v3:
- code style fixes per David Ahern

v2:
- move logic from arch__compare_symbol_names to new map__compare_symbol_names
- call through from map__compare_symbol_names to arch__compare_symbol_names
- redirect uses of arch__compare_symbol_names
- send patch to LKML

 tools/perf/util/auxtrace.c |  2 +-
 tools/perf/util/map.c  | 23 +++
 tools/perf/util/map.h  |  3 ++-
 tools/perf/util/symbol.c   |  4 ++--
 4 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index c5a6e0b1..f3511a6 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -1875,7 +1875,7 @@ static bool dso_sym_match(struct symbol *sym, const char 
*name, int *cnt,
  int idx)
 {
/* Same name, and global or the n'th found or any */
-   return !arch__compare_symbol_names(name, sym->name) &&
+   return !map__compare_symbol_names(name, sym->name) &&
   ((!idx && sym->binding == STB_GLOBAL) ||
(idx > 0 && ++*cnt == idx) ||
idx < 0);
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 4f9a71c..26a3e87 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -330,6 +330,29 @@ int __weak arch__compare_symbol_names(const char *namea, 
const char *nameb)
return strcmp(namea, nameb);
 }
 
+int map__compare_symbol_names(const char *namea, const char *nameb)

+{
+   int rc;
+   const char *namea_versioning, *nameb_versioning;
+
+   namea_versioning = strstr(namea,"@@");
+   if (namea_versioning)
+   namea = strndup(namea,namea_versioning-namea);
+
+   nameb_versioning = strstr(nameb,"@@");
+   if (nameb_versioning)
+   nameb = strndup(nameb,nameb_versioning-nameb);
+
+   rc = arch__compare_symbol_names(namea, nameb);
+
+   if (namea_versioning)
+   free((void *)namea);
+   if (nameb_versioning)
+   free((void *)nameb);
+
+   return rc;
+}
+
 struct symbol *map__find_symbol(struct map *map, u64 addr)
 {
if (map__load(map) < 0)
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index abdacf8..aaad64d 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -130,13 +130,14 @@ struct thread;
  */
 #define __map__for_each_symbol_by_name(map, sym_name, pos) \
for (pos = map__find_symbol_by_name(map, sym_name); \
-pos && arch__compare_symbol_names(pos->name, sym_name) == 0;\
+pos && map__compare_symbol_names(pos->name, sym_name) == 0; \
 pos = symbol__next_by_name(pos))
 
 #define map__for_each_symbol_by_name(map, sym_name, pos)		\

[PATCH v2] Allow user probes on versioned symbols

2017-03-30 Thread Paul Clarke

_name(pos))
 
 #define map__for_each_symbol_by_name(map, sym_name, pos)		\

__map__for_each_symbol_by_name(map, sym_name, (pos))
 
 int arch__compare_symbol_names(const char *namea, const char *nameb);

+int map__compare_symbol_names(const char *namea, const char *nameb);
 void map__init(struct map *map, enum map_type type,
   u64 start, u64 end, u64 pgoff, struct dso *dso);
 struct map *map__new(struct machine *machine, u64 start, u64 len,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index dc93940..4fb9d275 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -411,7 +411,7 @@ static struct symbol *symbols__find_by_name(struct rb_root 
*symbols,
int cmp;
 
 		s = rb_entry(n, struct symbol_name_rb_node, rb_node);

-   cmp = arch__compare_symbol_names(name, s->sym.name);
+   cmp = map__compare_symbol_names(name, s->sym.name);
 
 		if (cmp < 0)

n = n->rb_left;
@@ -429,7 +429,7 @@ static struct symbol *symbols__find_by_name(struct rb_root 
*symbols,
struct symbol_name_rb_node *tmp;
 
 		tmp = rb_entry(n, struct symbol_name_rb_node, rb_node);

-   if (arch__compare_symbol_names(tmp->sym.name, s->sym.name))
+       if (map__compare_symbol_names(tmp->sym.name, s->sym.name))
break;
 
 		s = tmp;

--
2.1.4

Regards,
Paul Clarke

[PATCH v2] Allow user probes on versioned symbols

2017-03-30 Thread Paul Clarke

 map__for_each_symbol_by_name(map, sym_name, pos)		\

__map__for_each_symbol_by_name(map, sym_name, (pos))
 
 int arch__compare_symbol_names(const char *namea, const char *nameb);

+int map__compare_symbol_names(const char *namea, const char *nameb);
 void map__init(struct map *map, enum map_type type,
   u64 start, u64 end, u64 pgoff, struct dso *dso);
 struct map *map__new(struct machine *machine, u64 start, u64 len,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index dc93940..4fb9d275 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -411,7 +411,7 @@ static struct symbol *symbols__find_by_name(struct rb_root 
*symbols,
int cmp;
 
 		s = rb_entry(n, struct symbol_name_rb_node, rb_node);

-   cmp = arch__compare_symbol_names(name, s->sym.name);
+   cmp = map__compare_symbol_names(name, s->sym.name);
 
 		if (cmp < 0)

n = n->rb_left;
@@ -429,7 +429,7 @@ static struct symbol *symbols__find_by_name(struct rb_root 
*symbols,
struct symbol_name_rb_node *tmp;
 
 		tmp = rb_entry(n, struct symbol_name_rb_node, rb_node);

-   if (arch__compare_symbol_names(tmp->sym.name, s->sym.name))
+   if (map__compare_symbol_names(tmp->sym.name, s->sym.name))
break;
 
 		s = tmp;

--
2.1.4

Regards,
Paul Clarke

Re: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable generic "cache-references" and "cache-misses" events)

2016-09-22 Thread Paul Clarke


On 09/22/2016 12:50 PM, Vineet Gupta wrote:

On 09/22/2016 12:56 AM, Peter Zijlstra wrote:

On Wed, Sep 21, 2016 at 07:43:28PM -0500, Paul Clarke wrote:

On 09/20/2016 03:56 PM, Vineet Gupta wrote:

On 09/01/2016 01:33 AM, Peter Zijlstra wrote:

- is that what perf event grouping is ?


Again, nope. Perf event groups are single counter (so no implicit
addition) that are co-scheduled on the PMU.


I'm not sure I understand - does this require specific PMU/arch support - as in
multiple conditions feeding to same counter.


My read is that is that what Peter meant was that each event in the
perf event group is a single counter, so all the events in the group
are counted simultaneously.  (No multiplexing.)


Right, sorry for the poor wording.


Again when you say co-scheduled what do you mean - why would anyone use the 
event
grouping - is it when they only have 1 counter and they want to count 2
conditions/events at the same time - isn't this same as event multiplexing ?


I'd say it's the converse of multiplexing.  Instead of mapping
multiple events to a single counter, perf event groups map a set of
events each to their own counter, and they are active simultaneously.
I suppose it's possible for the _groups_ to be multiplexed with other
events or groups, but the group as a whole will be scheduled together,
as a group.


Correct.

Each events get their own hardware counter. Grouped events are
co-scheduled on the hardware.


And if we don't group them, then they _may_ not be co-scheduled (active/counting
at the same time) ? But how can this be possible.
Say we have 2 counters, both the cmds below

 perf -e cycles,instructions hackbench
 perf -e {cycles,instructions} hackbench

would assign 2 counters to the 2 conditions which keep counting until perf asks
them to stop (because the profiled application ended)

I don't understand the "scheduling" of counter - once we set them to count, 
there
is no real intervention/scheduling form software in terms of disabling/enabling
(assuming no multiplexing etc)


If you assume no multiplexing, then this discussion on grouping is moot.

It depends on how many events you specify, how many counters there are, and 
which counters can count which events.  If you specify a set of events for 
which every event can be counted simultaneously, they will be scheduled 
simultaneously and continuously.  If you specify more events than counters, 
there's multiplexing.  AND, if you specify a set of events, some of which 
cannot be counted simultaneously due to hardware limitations, they'll be 
multiplexed.

PC

Re: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable generic "cache-references" and "cache-misses" events)

2016-09-22 Thread Paul Clarke


On 09/22/2016 12:50 PM, Vineet Gupta wrote:

On 09/22/2016 12:56 AM, Peter Zijlstra wrote:

On Wed, Sep 21, 2016 at 07:43:28PM -0500, Paul Clarke wrote:

On 09/20/2016 03:56 PM, Vineet Gupta wrote:

On 09/01/2016 01:33 AM, Peter Zijlstra wrote:

- is that what perf event grouping is ?


Again, nope. Perf event groups are single counter (so no implicit
addition) that are co-scheduled on the PMU.


I'm not sure I understand - does this require specific PMU/arch support - as in
multiple conditions feeding to same counter.


My read is that is that what Peter meant was that each event in the
perf event group is a single counter, so all the events in the group
are counted simultaneously.  (No multiplexing.)


Right, sorry for the poor wording.


Again when you say co-scheduled what do you mean - why would anyone use the 
event
grouping - is it when they only have 1 counter and they want to count 2
conditions/events at the same time - isn't this same as event multiplexing ?


I'd say it's the converse of multiplexing.  Instead of mapping
multiple events to a single counter, perf event groups map a set of
events each to their own counter, and they are active simultaneously.
I suppose it's possible for the _groups_ to be multiplexed with other
events or groups, but the group as a whole will be scheduled together,
as a group.


Correct.

Each events get their own hardware counter. Grouped events are
co-scheduled on the hardware.


And if we don't group them, then they _may_ not be co-scheduled (active/counting
at the same time) ? But how can this be possible.
Say we have 2 counters, both the cmds below

 perf -e cycles,instructions hackbench
 perf -e {cycles,instructions} hackbench

would assign 2 counters to the 2 conditions which keep counting until perf asks
them to stop (because the profiled application ended)

I don't understand the "scheduling" of counter - once we set them to count, 
there
is no real intervention/scheduling form software in terms of disabling/enabling
(assuming no multiplexing etc)


If you assume no multiplexing, then this discussion on grouping is moot.

It depends on how many events you specify, how many counters there are, and 
which counters can count which events.  If you specify a set of events for 
which every event can be counted simultaneously, they will be scheduled 
simultaneously and continuously.  If you specify more events than counters, 
there's multiplexing.  AND, if you specify a set of events, some of which 
cannot be counted simultaneously due to hardware limitations, they'll be 
multiplexed.

PC

Re: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable generic "cache-references" and "cache-misses" events)

2016-09-21 Thread Paul Clarke


On 09/20/2016 03:56 PM, Vineet Gupta wrote:

On 09/01/2016 01:33 AM, Peter Zijlstra wrote:

- is that what perf event grouping is ?


Again, nope. Perf event groups are single counter (so no implicit
addition) that are co-scheduled on the PMU.


I'm not sure I understand - does this require specific PMU/arch support - as in
multiple conditions feeding to same counter.


My read is that is that what Peter meant was that each event in the perf event 
group is a single counter, so all the events in the group are counted 
simultaneously.  (No multiplexing.)


You can do it like:

perf stat -e '{cycles,instructions}'

Which will place the cycles event and the instructions event in a group
and thereby guarantee they're co-scheduled.


Again when you say co-scheduled what do you mean - why would anyone use the 
event
grouping - is it when they only have 1 counter and they want to count 2
conditions/events at the same time - isn't this same as event multiplexing ?


I'd say it's the converse of multiplexing.  Instead of mapping multiple events 
to a single counter, perf event groups map a set of events each to their own 
counter, and they are active simultaneously.  I suppose it's possible for the 
_groups_ to be multiplexed with other events or groups, but the group as a 
whole will be scheduled together, as a group.

If you have a single counter, I don't believe you can support perf event 
groups, by definition.

Regards,
Paul Clarke, IBM

Re: perf event grouping for dummies (was Re: [PATCH] arc: perf: Enable generic "cache-references" and "cache-misses" events)

2016-09-21 Thread Paul Clarke


On 09/20/2016 03:56 PM, Vineet Gupta wrote:

On 09/01/2016 01:33 AM, Peter Zijlstra wrote:

- is that what perf event grouping is ?


Again, nope. Perf event groups are single counter (so no implicit
addition) that are co-scheduled on the PMU.


I'm not sure I understand - does this require specific PMU/arch support - as in
multiple conditions feeding to same counter.


My read is that is that what Peter meant was that each event in the perf event 
group is a single counter, so all the events in the group are counted 
simultaneously.  (No multiplexing.)


You can do it like:

perf stat -e '{cycles,instructions}'

Which will place the cycles event and the instructions event in a group
and thereby guarantee they're co-scheduled.


Again when you say co-scheduled what do you mean - why would anyone use the 
event
grouping - is it when they only have 1 counter and they want to count 2
conditions/events at the same time - isn't this same as event multiplexing ?


I'd say it's the converse of multiplexing.  Instead of mapping multiple events 
to a single counter, perf event groups map a set of events each to their own 
counter, and they are active simultaneously.  I suppose it's possible for the 
_groups_ to be multiplexed with other events or groups, but the group as a 
whole will be scheduled together, as a group.

If you have a single counter, I don't believe you can support perf event 
groups, by definition.

Regards,
Paul Clarke, IBM

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

2016-08-05 Thread Paul Clarke


Only nits from me...(see below)

On 08/05/2016 01:30 PM, Sukadev Bhattiprolu wrote:

Here is an updated patch to fix the build when CONFIG_PPC_PSERIES=n.
---
From d4f77a6ca7b6ea83f6588e7d541cc70bf001ae85 Mon Sep 17 00:00:00 2001
From: root 
Date: Thu, 4 Aug 2016 23:13:37 -0400
Subject: [PATCH 2/2] powerpc/pseries: Dynamically grow RMA size

When booting a very large system with a larg initrd we run out of space
for the flattened device tree (FDT). To fix this we must increase the
space allocated for the RMA region.

The RMA size is hard-coded in the 'ibm_architecture_vec[]' and increasing
the size there will apply to all systems, small and large, so we want to
increase the RMA region only when necessary.

When we run out of room for the FDT, set a new OF property, 'ibm,new-rma-size'
to the new RMA size (512MB) and issue a client-architecture-support (CAS)
call to the firmware. This will initiate a system reboot. Upon reboot we
notice the new property and update the RMA size accordingly.

Fix suggested by Michael Ellerman.

Signed-off-by: Sukadev Bhattiprolu 
---

[v2]:   - Add a comment in code regarding 'fixup_nr_cores_done'
- Fix build break when CONFIG_PPC_PSERIES=n
---
 arch/powerpc/kernel/prom_init.c | 96 -
 1 file changed, 95 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index f612a99..cbd5387 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -679,6 +679,7 @@ unsigned char ibm_architecture_vec[] = {
W(0x),  /* virt_base */
W(0x),  /* virt_size */
W(0x),  /* load_base */
+#define IBM_ARCH_VEC_MIN_RMA_OFFSET108
W(256), /* 256MB min RMA */
W(0x),  /* full client load */
0,  /* min RMA percentage of total RAM */
@@ -867,6 +868,14 @@ static void fixup_nr_cores(void)
 {
u32 cores;
unsigned char *ptcores;
+   static bool fixup_nr_cores_done = false;
+
+   /*
+* If this is a second CAS call in the same boot sequence, (see
+* increase_rma_size()), we don't need to do the fixup again.
+*/
+   if (fixup_nr_cores_done)
+   return;

/* We need to tell the FW about the number of cores we support.
 *
@@ -898,6 +907,41 @@ static void fixup_nr_cores(void)
ptcores[1] = (cores >> 16) & 0xff;
ptcores[2] = (cores >> 8) & 0xff;
ptcores[3] = cores & 0xff;
+   fixup_nr_cores_done = true;
+   }
+}
+
+static void __init fixup_rma_size(void)
+{
+   int rc;
+   u64 size;
+   unsigned char *min_rmap;
+   phandle optnode;
+   char str[64];
+
+   optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+   if (!PHANDLE_VALID(optnode))
+   prom_panic("Cannot find /options");
+
+   /*
+* If a prior boot specified a new RMA size, use that size in
+* ibm_architecture_vec[]. See also increase_rma_size().
+*/
+   size = 0ULL;
+   memset(str, 0, sizeof(str));
+   rc = prom_getprop(optnode, "ibm,new-rma-size", , sizeof(str));
+   if (rc <= 0)
+   return;
+
+   size = prom_strtoul(str, NULL);
+   min_rmap = _architecture_vec[IBM_ARCH_VEC_MIN_RMA_OFFSET];
+
+   if (size) {
+   prom_printf("Using RMA size %lu from ibm,new-rma-size.\n", 
size);
+   min_rmap[0] = (size >> 24) & 0xff;
+   min_rmap[1] = (size >> 16) & 0xff;
+   min_rmap[2] = (size >> 8) & 0xff;
+   min_rmap[3] = size & 0xff;
}
 }

@@ -911,6 +955,8 @@ static void __init prom_send_capabilities(void)

fixup_nr_cores();

+   fixup_rma_size();
+
/* try calling the ibm,client-architecture-support method */
prom_printf("Calling ibm,client-architecture-support...");
if (call_prom_ret("call-method", 3, 2, ,
@@ -946,6 +992,52 @@ static void __init prom_send_capabilities(void)
}
 #endif /* __BIG_ENDIAN__ */
 }
+
+static void __init increase_rma_size(void)
+{
+   int rc;
+   u64 size;
+   char str[64];
+   phandle optnode;
+
+   optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+   if (!PHANDLE_VALID(optnode))
+   prom_panic("Cannot find /options");
+
+   /*
+* If we already increased the RMA size, return.
+*/
+   size = 0ULL;
+   memset(str, 0, sizeof(str));
+   rc = prom_getprop(optnode, "ibm,new-rma-size", , sizeof(str));
+
+   size = prom_strtoul(str, NULL);
+   if (size == 512ULL) {


Is this preferred over strncmp?  Using a string also helps with my suggestion 
below...


+   prom_printf("RMA

Re: [PATCH 2/2] powerpc/pseries: Dynamically increase RMA size

2016-08-05 Thread Paul Clarke


Only nits from me...(see below)

On 08/05/2016 01:30 PM, Sukadev Bhattiprolu wrote:

Here is an updated patch to fix the build when CONFIG_PPC_PSERIES=n.
---
From d4f77a6ca7b6ea83f6588e7d541cc70bf001ae85 Mon Sep 17 00:00:00 2001
From: root 
Date: Thu, 4 Aug 2016 23:13:37 -0400
Subject: [PATCH 2/2] powerpc/pseries: Dynamically grow RMA size

When booting a very large system with a larg initrd we run out of space
for the flattened device tree (FDT). To fix this we must increase the
space allocated for the RMA region.

The RMA size is hard-coded in the 'ibm_architecture_vec[]' and increasing
the size there will apply to all systems, small and large, so we want to
increase the RMA region only when necessary.

When we run out of room for the FDT, set a new OF property, 'ibm,new-rma-size'
to the new RMA size (512MB) and issue a client-architecture-support (CAS)
call to the firmware. This will initiate a system reboot. Upon reboot we
notice the new property and update the RMA size accordingly.

Fix suggested by Michael Ellerman.

Signed-off-by: Sukadev Bhattiprolu 
---

[v2]:   - Add a comment in code regarding 'fixup_nr_cores_done'
- Fix build break when CONFIG_PPC_PSERIES=n
---
 arch/powerpc/kernel/prom_init.c | 96 -
 1 file changed, 95 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index f612a99..cbd5387 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -679,6 +679,7 @@ unsigned char ibm_architecture_vec[] = {
W(0x),  /* virt_base */
W(0x),  /* virt_size */
W(0x),  /* load_base */
+#define IBM_ARCH_VEC_MIN_RMA_OFFSET108
W(256), /* 256MB min RMA */
W(0x),  /* full client load */
0,  /* min RMA percentage of total RAM */
@@ -867,6 +868,14 @@ static void fixup_nr_cores(void)
 {
u32 cores;
unsigned char *ptcores;
+   static bool fixup_nr_cores_done = false;
+
+   /*
+* If this is a second CAS call in the same boot sequence, (see
+* increase_rma_size()), we don't need to do the fixup again.
+*/
+   if (fixup_nr_cores_done)
+   return;

/* We need to tell the FW about the number of cores we support.
 *
@@ -898,6 +907,41 @@ static void fixup_nr_cores(void)
ptcores[1] = (cores >> 16) & 0xff;
ptcores[2] = (cores >> 8) & 0xff;
ptcores[3] = cores & 0xff;
+   fixup_nr_cores_done = true;
+   }
+}
+
+static void __init fixup_rma_size(void)
+{
+   int rc;
+   u64 size;
+   unsigned char *min_rmap;
+   phandle optnode;
+   char str[64];
+
+   optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+   if (!PHANDLE_VALID(optnode))
+   prom_panic("Cannot find /options");
+
+   /*
+* If a prior boot specified a new RMA size, use that size in
+* ibm_architecture_vec[]. See also increase_rma_size().
+*/
+   size = 0ULL;
+   memset(str, 0, sizeof(str));
+   rc = prom_getprop(optnode, "ibm,new-rma-size", , sizeof(str));
+   if (rc <= 0)
+   return;
+
+   size = prom_strtoul(str, NULL);
+   min_rmap = _architecture_vec[IBM_ARCH_VEC_MIN_RMA_OFFSET];
+
+   if (size) {
+   prom_printf("Using RMA size %lu from ibm,new-rma-size.\n", 
size);
+   min_rmap[0] = (size >> 24) & 0xff;
+   min_rmap[1] = (size >> 16) & 0xff;
+   min_rmap[2] = (size >> 8) & 0xff;
+   min_rmap[3] = size & 0xff;
}
 }

@@ -911,6 +955,8 @@ static void __init prom_send_capabilities(void)

fixup_nr_cores();

+   fixup_rma_size();
+
/* try calling the ibm,client-architecture-support method */
prom_printf("Calling ibm,client-architecture-support...");
if (call_prom_ret("call-method", 3, 2, ,
@@ -946,6 +992,52 @@ static void __init prom_send_capabilities(void)
}
 #endif /* __BIG_ENDIAN__ */
 }
+
+static void __init increase_rma_size(void)
+{
+   int rc;
+   u64 size;
+   char str[64];
+   phandle optnode;
+
+   optnode = call_prom("finddevice", 1, 1, ADDR("/options"));
+   if (!PHANDLE_VALID(optnode))
+   prom_panic("Cannot find /options");
+
+   /*
+* If we already increased the RMA size, return.
+*/
+   size = 0ULL;
+   memset(str, 0, sizeof(str));
+   rc = prom_getprop(optnode, "ibm,new-rma-size", , sizeof(str));
+
+   size = prom_strtoul(str, NULL);
+   if (size == 512ULL) {


Is this preferred over strncmp?  Using a string also helps with my suggestion 
below...


+   prom_printf("RMA size already at %lu.\n", size);
+   return;
+

Re: [PATCH] cpufreq: powernv: Redesign the presentation of throttle notification

2015-12-14 Thread Paul Clarke


On 12/13/2015 12:17 PM, Shilpasri G Bhat wrote:

Replace the throttling event console messages to perf trace event
"power:powernv_throttle" and throttle counter stats which are
exported in sysfs. The newly added sysfs files are as follows:

1)/sys/devices/system/node/node0/throttle_frequencies
   This gives the throttle stats for each of the available frequencies.
   The throttle stat of a frequency is the total number of times the max
   frequency was reduced to that frequency.
   # cat /sys/devices/system/node/node0/throttle_frequencies
   4023000 0
   399 0
   3956000 1
   3923000 0
   389 0
   3857000 2
   3823000 0
   379 0
   3757000 2
   3724000 1
   369 1
   ...


Is this data useful?  It seems like "elapsed time" at each frequency might be 
more useful, if any.



2)/sys/devices/system/node/node0/throttle_reasons
   This gives the stats for each of the supported throttle reasons.
   This gives the total number of times the frequency was throttled due
   to each of the reasons.
   # cat /sys/devices/system/node/node0/throttle_reasons
   No throttling 7
   Power Cap 0
   Processor Over Temperature 7
   Power Supply Failure 0
   Over Current 0
   OCC Reset 0

3)/sys/devices/system/node/node0/throttle_stat
   This gives the total number of throttle events occurred in turbo
   range of frequencies and non-turbo(below nominal) range of
   frequencies.


non-turbo should read "at or below nominal".  Maybe "sub-turbo" is a better 
term(?)



   # cat /sys/devices/system/node/node0/throttle_stat
   Turbo 7
   Nominal 0


Should this read "Non-turbo" or "Sub-turbo" instead of "Nominal", since the 
events could well occur when already operating below nominal.



Signed-off-by: Shilpasri G Bhat 
---
  drivers/cpufreq/powernv-cpufreq.c | 186 +-
  include/trace/events/power.h  |  22 +
  2 files changed, 166 insertions(+), 42 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index cb50138..bdde9d6 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -28,6 +28,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  #include 
  #include 
@@ -43,12 +46,27 @@
  static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
  static bool rebooting, throttled, occ_reset;

+static char throttle_reason[][30] = {
+   "No throttling",
+   "Power Cap",
+   "Processor Over Temperature",
+   "Power Supply Failure",
+   "Over Current",
+   "OCC Reset"
+};


I'm curious if this would be slightly more efficiently implemented as:
static const char *throttle_reason[] = { ... };

Do you need 30 characters per string for a reason?

Regardless, it should be const.

[...]
--
PC

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq: powernv: Redesign the presentation of throttle notification

2015-12-14 Thread Paul Clarke


On 12/13/2015 12:17 PM, Shilpasri G Bhat wrote:

Replace the throttling event console messages to perf trace event
"power:powernv_throttle" and throttle counter stats which are
exported in sysfs. The newly added sysfs files are as follows:

1)/sys/devices/system/node/node0/throttle_frequencies
   This gives the throttle stats for each of the available frequencies.
   The throttle stat of a frequency is the total number of times the max
   frequency was reduced to that frequency.
   # cat /sys/devices/system/node/node0/throttle_frequencies
   4023000 0
   399 0
   3956000 1
   3923000 0
   389 0
   3857000 2
   3823000 0
   379 0
   3757000 2
   3724000 1
   369 1
   ...


Is this data useful?  It seems like "elapsed time" at each frequency might be 
more useful, if any.



2)/sys/devices/system/node/node0/throttle_reasons
   This gives the stats for each of the supported throttle reasons.
   This gives the total number of times the frequency was throttled due
   to each of the reasons.
   # cat /sys/devices/system/node/node0/throttle_reasons
   No throttling 7
   Power Cap 0
   Processor Over Temperature 7
   Power Supply Failure 0
   Over Current 0
   OCC Reset 0

3)/sys/devices/system/node/node0/throttle_stat
   This gives the total number of throttle events occurred in turbo
   range of frequencies and non-turbo(below nominal) range of
   frequencies.


non-turbo should read "at or below nominal".  Maybe "sub-turbo" is a better 
term(?)



   # cat /sys/devices/system/node/node0/throttle_stat
   Turbo 7
   Nominal 0


Should this read "Non-turbo" or "Sub-turbo" instead of "Nominal", since the 
events could well occur when already operating below nominal.



Signed-off-by: Shilpasri G Bhat 
---
  drivers/cpufreq/powernv-cpufreq.c | 186 +-
  include/trace/events/power.h  |  22 +
  2 files changed, 166 insertions(+), 42 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index cb50138..bdde9d6 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -28,6 +28,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

  #include 
  #include 
@@ -43,12 +46,27 @@
  static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
  static bool rebooting, throttled, occ_reset;

+static char throttle_reason[][30] = {
+   "No throttling",
+   "Power Cap",
+   "Processor Over Temperature",
+   "Power Supply Failure",
+   "Over Current",
+   "OCC Reset"
+};


I'm curious if this would be slightly more efficiently implemented as:
static const char *throttle_reason[] = { ... };

Do you need 30 characters per string for a reason?

Regardless, it should be const.

[...]
--
PC

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH perf/core ] [BUGFIX] perf probe: Fix a segfault when removing uprobe events

2015-09-18 Thread Paul Clarke


On 09/16/2015 07:52 AM, Masami Hiramatsu wrote:

Fix a segfault bug and a small mistake in perf probe -d.

Since the "ulist" in perf_del_probe_events is never initialized,
strlist__add(ulist, *) always causes a segfault when removing
uprobe events by perf probe -d.

Also, the "str" local variable is never released if fail to
allocate the "klist". This fixes it too.

This has been introduced by the commit e607f1426b58 ("perf probe:
Print deleted events in cmd_probe()").

Reported-by: Milian Wolff 
Signed-off-by: Masami Hiramatsu 
---
  tools/perf/builtin-probe.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 94385ee..f7882ae 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -380,8 +380,11 @@ static int perf_del_probe_events(struct strfilter *filter)
goto out;

klist = strlist__new(NULL, NULL);
-   if (!klist)
-   return -ENOMEM;
+   ulist = strlist__new(NULL, NULL);
+   if (!klist || !ulist) {
+   ret = -ENOMEM;
+   goto out;
+   }


Newbie here, but if one of "strlist__new()" calls succeeds, don't you 
need a corresponding strlist__delete() ?


PC

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH perf/core ] [BUGFIX] perf probe: Fix a segfault when removing uprobe events

2015-09-18 Thread Paul Clarke


On 09/16/2015 07:52 AM, Masami Hiramatsu wrote:

Fix a segfault bug and a small mistake in perf probe -d.

Since the "ulist" in perf_del_probe_events is never initialized,
strlist__add(ulist, *) always causes a segfault when removing
uprobe events by perf probe -d.

Also, the "str" local variable is never released if fail to
allocate the "klist". This fixes it too.

This has been introduced by the commit e607f1426b58 ("perf probe:
Print deleted events in cmd_probe()").

Reported-by: Milian Wolff 
Signed-off-by: Masami Hiramatsu 
---
  tools/perf/builtin-probe.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 94385ee..f7882ae 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -380,8 +380,11 @@ static int perf_del_probe_events(struct strfilter *filter)
goto out;

klist = strlist__new(NULL, NULL);
-   if (!klist)
-   return -ENOMEM;
+   ulist = strlist__new(NULL, NULL);
+   if (!klist || !ulist) {
+   ret = -ENOMEM;
+   goto out;
+   }


Newbie here, but if one of "strlist__new()" calls succeeds, don't you 
need a corresponding strlist__delete() ?


PC

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] powerpc: re-enable dynticks

2015-02-20 Thread Paul Clarke



implement arch_irq_work_has_interrupt() for powerpc

(resending because I messed up the e-mail addresses)

Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for 
full dynamic ticks to be enabled, by expecting architectures to 
implement a suitable arch_irq_work_has_interrupt() routine.


Several arches have implemented this routine, including x86 (3010279f) 
and arm (09f6edd4), but powerpc was omitted.


This patch implements this routine for powerpc.

The symptom, at boot (on powerpc arch systems) with "nohz_full=list>" is displayed:
NO_HZ: Can't run full dynticks because arch doesn't support irq 
work self-IPIs


after this patch:
NO_HZ: Full dynticks CPUs: .

Tested against 3.19.

v2: changed "return 1" to "return true", per Michael Ellerman

CC: Frederic Weisbecker 
CC: Paul E. McKenney 
Signed-off-by: Paul A. Clarke 

diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h

new file mode 100644
index 000..99cc0aa
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include 
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+return true;
+}
+
+#endif /* _ASM_IRQ_WORK_H */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] powerpc: re-enable dynticks

2015-02-20 Thread Paul Clarke


implement arch_irq_work_has_interrupt() for powerpc

Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for 
full dynamic ticks to be enabled, by expecting architectures to 
implement a suitable arch_irq_work_has_interrupt() routine.


Several arches have implemented this routine, including x86 (3010279f) 
and arm (09f6edd4), but powerpc was omitted.


This patch implements this routine for powerpc.

The symptom, at boot (on powerpc arch systems) with "nohz_full=list>" is displayed:
NO_HZ: Can't run full dynticks because arch doesn't support irq 
work self-IPIs


after this patch:
NO_HZ: Full dynticks CPUs: .

Tested against 3.19.

v2: changed "return 1" to "return true", per Michael Ellerman

CC: Frederic Weisbecker 
CC: Paul E. McKenney 
Signed-off-by: Paul A. Clarke 

diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h

new file mode 100644
index 000..99cc0aa
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include 
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+   return true;
+}
+
+#endif /* _ASM_IRQ_WORK_H */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] powerpc: re-enable dynticks

2015-02-20 Thread Paul Clarke


implement arch_irq_work_has_interrupt() for powerpc

Commit 9b01f5bf3 introduced a dependency on IRQ work self-IPIs for 
full dynamic ticks to be enabled, by expecting architectures to 
implement a suitable arch_irq_work_has_interrupt() routine.


Several arches have implemented this routine, including x86 (3010279f) 
and arm (09f6edd4), but powerpc was omitted.


This patch implements this routine for powerpc.

The symptom, at boot (on powerpc arch systems) with nohz_full=CPU 
list is displayed:
NO_HZ: Can't run full dynticks because arch doesn't support irq 
work self-IPIs


after this patch:
NO_HZ: Full dynticks CPUs: CPU list.

Tested against 3.19.

v2: changed return 1 to return true, per Michael Ellerman

CC: Frederic Weisbecker fweis...@gmail.com
CC: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Paul A. Clarke p...@us.ibm.com

diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h

new file mode 100644
index 000..99cc0aa
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include asm/processor.h
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+   return true;
+}
+
+#endif /* _ASM_IRQ_WORK_H */

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] powerpc: re-enable dynticks

2015-02-20 Thread Paul Clarke



implement arch_irq_work_has_interrupt() for powerpc

(resending because I messed up the e-mail addresses)

Commit 9b01f5bf3 introduced a dependency on IRQ work self-IPIs for 
full dynamic ticks to be enabled, by expecting architectures to 
implement a suitable arch_irq_work_has_interrupt() routine.


Several arches have implemented this routine, including x86 (3010279f) 
and arm (09f6edd4), but powerpc was omitted.


This patch implements this routine for powerpc.

The symptom, at boot (on powerpc arch systems) with nohz_full=CPU 
list is displayed:
NO_HZ: Can't run full dynticks because arch doesn't support irq 
work self-IPIs


after this patch:
NO_HZ: Full dynticks CPUs: CPU list.

Tested against 3.19.

v2: changed return 1 to return true, per Michael Ellerman

CC: Frederic Weisbecker fweis...@gmail.com
CC: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Paul A. Clarke p...@us.ibm.com

diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h

new file mode 100644
index 000..99cc0aa
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include asm/processor.h
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+return true;
+}
+
+#endif /* _ASM_IRQ_WORK_H */

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] powerpc: re-enable dynticks

2015-02-13 Thread Paul Clarke


implement arch_irq_work_has_interrupt() for powerpc

Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for 
full dynamic ticks to be enabled, by expecting architectures to 
implement a suitable arch_irq_work_has_interrupt() routine.


Several arches have implemented this routine, including x86 (3010279f) 
and arm (09f6edd4), but powerpc was omitted.


This patch implements this routine for powerpc.

The symptom, at boot (on powerpc arch systems) with "nohz_full=list>" is displayed:
NO_HZ: Can't run full dynticks because arch doesn't support irq 
work self-IPIs


after this patch:
NO_HZ: Full dynticks CPUs: .

Tested against 3.19.

CC: Frederic Weisbecker 
CC: Paul E. McKenney 
Signed-off-by: Paul A. Clarke 

diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h

new file mode 100644
index 000..18365ec
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include 
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+   return 1;
+}
+
+#endif /* _ASM_IRQ_WORK_H */

--
Regards,
Paul Clarke, IBM

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] powerpc: re-enable dynticks

2015-02-13 Thread Paul Clarke


implement arch_irq_work_has_interrupt() for powerpc

Commit 9b01f5bf3 introduced a dependency on IRQ work self-IPIs for 
full dynamic ticks to be enabled, by expecting architectures to 
implement a suitable arch_irq_work_has_interrupt() routine.


Several arches have implemented this routine, including x86 (3010279f) 
and arm (09f6edd4), but powerpc was omitted.


This patch implements this routine for powerpc.

The symptom, at boot (on powerpc arch systems) with nohz_full=CPU 
list is displayed:
NO_HZ: Can't run full dynticks because arch doesn't support irq 
work self-IPIs


after this patch:
NO_HZ: Full dynticks CPUs: CPU list.

Tested against 3.19.

CC: Frederic Weisbecker fweis...@gmail.com
CC: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Paul A. Clarke p...@us.ibm.com

diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h

new file mode 100644
index 000..18365ec
--- /dev/null
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -0,0 +1,11 @@
+#ifndef _ASM_IRQ_WORK_H
+#define _ASM_IRQ_WORK_H
+
+#include asm/processor.h
+
+static inline bool arch_irq_work_has_interrupt(void)
+{
+   return 1;
+}
+
+#endif /* _ASM_IRQ_WORK_H */

--
Regards,
Paul Clarke, IBM

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

85 matches

Mail list logo