Re: unknown NMI on AMD Rome
On 3/16/21 2:53 PM, Peter Zijlstra wrote: > On Tue, Mar 16, 2021 at 04:45:02PM +0100, Jiri Olsa wrote: >> hi, >> when running 'perf top' on AMD Rome (/proc/cpuinfo below) >> with fedora 33 kernel 5.10.22-200.fc33.x86_64 >> >> we got unknown NMI messages: >> >> [ 226.700160] Uhhuh. NMI received for unknown reason 3d on CPU 90. >> [ 226.700162] Do you have a strange power saving mode enabled? >> [ 226.700163] Dazed and confused, but trying to continue >> [ 226.769565] Uhhuh. NMI received for unknown reason 3d on CPU 84. >> [ 226.769566] Do you have a strange power saving mode enabled? >> [ 226.769567] Dazed and confused, but trying to continue >> [ 226.769771] Uhhuh. NMI received for unknown reason 2d on CPU 24. >> [ 226.769773] Do you have a strange power saving mode enabled? >> [ 226.769774] Dazed and confused, but trying to continue >> [ 226.812844] Uhhuh. NMI received for unknown reason 2d on CPU 23. >> [ 226.812846] Do you have a strange power saving mode enabled? >> [ 226.812847] Dazed and confused, but trying to continue >> [ 226.893783] Uhhuh. NMI received for unknown reason 2d on CPU 27. >> [ 226.893785] Do you have a strange power saving mode enabled? >> [ 226.893786] Dazed and confused, but trying to continue >> [ 226.900139] Uhhuh. NMI received for unknown reason 2d on CPU 40. >> [ 226.900141] Do you have a strange power saving mode enabled? >> [ 226.900143] Dazed and confused, but trying to continue >> [ 226.908763] Uhhuh. NMI received for unknown reason 3d on CPU 120. >> [ 226.908765] Do you have a strange power saving mode enabled? >> [ 226.908766] Dazed and confused, but trying to continue >> [ 227.751296] Uhhuh. NMI received for unknown reason 2d on CPU 83. >> [ 227.751298] Do you have a strange power saving mode enabled? >> [ 227.751299] Dazed and confused, but trying to continue >> [ 227.752937] Uhhuh. NMI received for unknown reason 3d on CPU 23. >> >> also when discussing ths with Borislav, he managed to reproduce easily >> on his AMD Rome machine >> >> any idea? > > Kim is the AMD point person for this I think.. Since perf top invokes precision and therefore IBS, this looks like it's hitting erratum #1215: https://developer.amd.com/wp-content/resources/56323-PUB_0.78.pdf Kim
[PATCH v2 2/4] powercap/intel_rapl_msr: Convert rapl_msr_priv into pointer
From: Victor Ding
This patch changes the static struct rapl_msr_priv to a pointer to allow
using a different set of of RAPL MSR interface, preparing for supporting
AMD's RAPL MSR interface.
No functional changes.
Signed-off-by: Victor Ding
Acked-by: Kim Phillips
Cc: Victor Ding
Cc: Alexander Shishkin
Cc: Borislav Petkov
Cc: Daniel Lezcano
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Pawan Gupta
Cc: "Peter Zijlstra (Intel)"
Cc: "Rafael J. Wysocki"
Cc: Sean Christopherson
Cc: Thomas Gleixner
Cc: Tony Luck
Cc: Vineela Tummalapalli
Cc: LKML
Cc: linux...@vger.kernel.org
Cc: x...@kernel.org
---
Kim's changes from Victor's original submission:
https://lore.kernel.org/lkml/20200729205144.2.I4cb96a95365506b77761c1416258672a7556b595@changeid/
- Added my Acked-by.
- Added Daniel Lezcano to Cc.
drivers/powercap/intel_rapl_msr.c | 37 +--
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/powercap/intel_rapl_msr.c
b/drivers/powercap/intel_rapl_msr.c
index d2a2627507a9..c68ef5e4e1c4 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -31,7 +31,9 @@
#define MSR_VR_CURRENT_CONFIG 0x0601
/* private data for RAPL MSR Interface */
-static struct rapl_if_priv rapl_msr_priv = {
+static struct rapl_if_priv *rapl_msr_priv;
+
+static struct rapl_if_priv rapl_msr_priv_intel = {
.reg_unit = MSR_RAPL_POWER_UNIT,
.regs[RAPL_DOMAIN_PACKAGE] = {
MSR_PKG_POWER_LIMIT, MSR_PKG_ENERGY_STATUS,
MSR_PKG_PERF_STATUS, 0, MSR_PKG_POWER_INFO },
@@ -57,9 +59,9 @@ static int rapl_cpu_online(unsigned int cpu)
{
struct rapl_package *rp;
- rp = rapl_find_package_domain(cpu, _msr_priv);
+ rp = rapl_find_package_domain(cpu, rapl_msr_priv);
if (!rp) {
- rp = rapl_add_package(cpu, _msr_priv);
+ rp = rapl_add_package(cpu, rapl_msr_priv);
if (IS_ERR(rp))
return PTR_ERR(rp);
}
@@ -72,7 +74,7 @@ static int rapl_cpu_down_prep(unsigned int cpu)
struct rapl_package *rp;
int lead_cpu;
- rp = rapl_find_package_domain(cpu, _msr_priv);
+ rp = rapl_find_package_domain(cpu, rapl_msr_priv);
if (!rp)
return 0;
@@ -135,44 +137,45 @@ static int rapl_msr_probe(struct platform_device *pdev)
const struct x86_cpu_id *id = x86_match_cpu(pl4_support_ids);
int ret;
- rapl_msr_priv.read_raw = rapl_msr_read_raw;
- rapl_msr_priv.write_raw = rapl_msr_write_raw;
+ rapl_msr_priv = _msr_priv_intel;
+ rapl_msr_priv->read_raw = rapl_msr_read_raw;
+ rapl_msr_priv->write_raw = rapl_msr_write_raw;
if (id) {
- rapl_msr_priv.limits[RAPL_DOMAIN_PACKAGE] = 3;
- rapl_msr_priv.regs[RAPL_DOMAIN_PACKAGE][RAPL_DOMAIN_REG_PL4] =
+ rapl_msr_priv->limits[RAPL_DOMAIN_PACKAGE] = 3;
+ rapl_msr_priv->regs[RAPL_DOMAIN_PACKAGE][RAPL_DOMAIN_REG_PL4] =
MSR_VR_CURRENT_CONFIG;
pr_info("PL4 support detected.\n");
}
- rapl_msr_priv.control_type = powercap_register_control_type(NULL,
"intel-rapl", NULL);
- if (IS_ERR(rapl_msr_priv.control_type)) {
+ rapl_msr_priv->control_type = powercap_register_control_type(NULL,
"intel-rapl", NULL);
+ if (IS_ERR(rapl_msr_priv->control_type)) {
pr_debug("failed to register powercap control_type.\n");
- return PTR_ERR(rapl_msr_priv.control_type);
+ return PTR_ERR(rapl_msr_priv->control_type);
}
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "powercap/rapl:online",
rapl_cpu_online, rapl_cpu_down_prep);
if (ret < 0)
goto out;
- rapl_msr_priv.pcap_rapl_online = ret;
+ rapl_msr_priv->pcap_rapl_online = ret;
/* Don't bail out if PSys is not supported */
- rapl_add_platform_domain(_msr_priv);
+ rapl_add_platform_domain(rapl_msr_priv);
return 0;
out:
if (ret)
- powercap_unregister_control_type(rapl_msr_priv.control_type);
+ powercap_unregister_control_type(rapl_msr_priv->control_type);
return ret;
}
static int rapl_msr_remove(struct platform_device *pdev)
{
- cpuhp_remove_state(rapl_msr_priv.pcap_rapl_online);
- rapl_remove_platform_domain(_msr_priv);
- powercap_unregister_control_type(rapl_msr_priv.control_type);
+ cpuhp_remove_state(rapl_msr_priv->pcap_rapl_online);
+ rapl_remove_platform_domain(rapl_msr_priv);
+ powercap_unregister_control_type(rapl_msr_priv->control_type);
return 0;
}
--
2.27.0
[PATCH v2 0/4] powercap: Enable RAPL for AMD Fam17h and Fam19h
From: Victor Ding This patch series adds support for AMD Fam17h RAPL counters. As per AMD PPR, Fam17h support RAPL counters to monitor power usage. The RAPL counter operates as with Intel RAPL. Therefore, it is beneficial to re-use existing framework for Intel, especially to allow existing tools to seamlessly run on AMD. >From the user's point view, this series enables the following two sysfs entry on AMD Fam17h: /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj /sys/class/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0/energy_uj Cc: Victor Ding Cc: Alexander Shishkin Cc: Borislav Petkov Cc: Daniel Lezcano Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Pawan Gupta Cc: "Peter Zijlstra (Intel)" Cc: "Rafael J. Wysocki" Cc: Sean Christopherson Cc: Thomas Gleixner Cc: Tony Luck Cc: Vineela Tummalapalli Cc: LKML Cc: linux...@vger.kernel.org Cc: x...@kernel.org Kim Phillips (1): powercap: Add AMD Fam19h RAPL support Victor Ding (3): x86/msr-index: sort AMD RAPL MSRs by address powercap/intel_rapl_msr: Convert rapl_msr_priv into pointer powercap: Add AMD Fam17h RAPL support arch/x86/include/asm/msr-index.h | 3 +- drivers/powercap/intel_rapl_common.c | 3 ++ drivers/powercap/intel_rapl_msr.c| 62 3 files changed, 50 insertions(+), 18 deletions(-) v2: Kim's changes from Victor's original submission: https://lore.kernel.org/lkml/20200729105206.2991064-1-victord...@google.com/ - Added the Fam19h patch to the end of the series - Added my Acked-by - Added Daniel Lezcano to Cc - (linux-pm was already on Cc) - (No code changes) -- 2.27.0
[PATCH v2 3/4] powercap: Add AMD Fam17h RAPL support
From: Victor Ding
This patch enables AMD Fam17h RAPL support for the power capping
framework. The support is as per AMD Fam17h Model31h (Zen2) and
model 00-ffh (Zen1) PPR.
Tested by comparing the results of following two sysfs entries and the
values directly read from corresponding MSRs via /dev/cpu/[x]/msr:
/sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
/sys/class/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0/energy_uj
Signed-off-by: Victor Ding
Acked-by: Kim Phillips
Cc: Victor Ding
Cc: Alexander Shishkin
Cc: Borislav Petkov
Cc: Daniel Lezcano
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Pawan Gupta
Cc: "Peter Zijlstra (Intel)"
Cc: "Rafael J. Wysocki"
Cc: Sean Christopherson
Cc: Thomas Gleixner
Cc: Tony Luck
Cc: Vineela Tummalapalli
Cc: LKML
Cc: linux...@vger.kernel.org
Cc: x...@kernel.org
---
Kim's changes from Victor's original submission:
https://lore.kernel.org/lkml/20200729205144.3.I01b89fb23d7498521c84cfdf417450cbbfca46bb@changeid/
- Added my Acked-by.
- Added Daniel Lezcano to Cc.
arch/x86/include/asm/msr-index.h | 1 +
drivers/powercap/intel_rapl_common.c | 2 ++
drivers/powercap/intel_rapl_msr.c| 27 ++-
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index f1b24f1b774d..c0646f69d2a5 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -324,6 +324,7 @@
#define MSR_PP1_POLICY 0x0642
#define MSR_AMD_RAPL_POWER_UNIT0xc0010299
+#define MSR_AMD_CORE_ENERGY_STATUS 0xc001029a
#define MSR_AMD_PKG_ENERGY_STATUS 0xc001029b
/* Config TDP MSRs */
diff --git a/drivers/powercap/intel_rapl_common.c
b/drivers/powercap/intel_rapl_common.c
index 983d75bd5bd1..6905ccffcec3 100644
--- a/drivers/powercap/intel_rapl_common.c
+++ b/drivers/powercap/intel_rapl_common.c
@@ -1054,6 +1054,8 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,
_defaults_hsw_server),
X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,
_defaults_hsw_server),
+
+ X86_MATCH_VENDOR_FAM(AMD, 0x17, _defaults_core),
{}
};
MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
diff --git a/drivers/powercap/intel_rapl_msr.c
b/drivers/powercap/intel_rapl_msr.c
index c68ef5e4e1c4..dcaef917f79d 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -48,6 +48,21 @@ static struct rapl_if_priv rapl_msr_priv_intel = {
.limits[RAPL_DOMAIN_PACKAGE] = 2,
};
+static struct rapl_if_priv rapl_msr_priv_amd = {
+ .reg_unit = MSR_AMD_RAPL_POWER_UNIT,
+ .regs[RAPL_DOMAIN_PACKAGE] = {
+ 0, MSR_AMD_PKG_ENERGY_STATUS, 0, 0, 0 },
+ .regs[RAPL_DOMAIN_PP0] = {
+ 0, MSR_AMD_CORE_ENERGY_STATUS, 0, 0, 0 },
+ .regs[RAPL_DOMAIN_PP1] = {
+ 0, 0, 0, 0, 0 },
+ .regs[RAPL_DOMAIN_DRAM] = {
+ 0, 0, 0, 0, 0 },
+ .regs[RAPL_DOMAIN_PLATFORM] = {
+ 0, 0, 0, 0, 0},
+ .limits[RAPL_DOMAIN_PACKAGE] = 1,
+};
+
/* Handles CPU hotplug on multi-socket systems.
* If a CPU goes online as the first CPU of the physical package
* we add the RAPL package to the system. Similarly, when the last
@@ -137,7 +152,17 @@ static int rapl_msr_probe(struct platform_device *pdev)
const struct x86_cpu_id *id = x86_match_cpu(pl4_support_ids);
int ret;
- rapl_msr_priv = _msr_priv_intel;
+ switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_INTEL:
+ rapl_msr_priv = _msr_priv_intel;
+ break;
+ case X86_VENDOR_AMD:
+ rapl_msr_priv = _msr_priv_amd;
+ break;
+ default:
+ pr_err("intel-rapl does not support CPU vendor %d\n",
boot_cpu_data.x86_vendor);
+ return -ENODEV;
+ }
rapl_msr_priv->read_raw = rapl_msr_read_raw;
rapl_msr_priv->write_raw = rapl_msr_write_raw;
--
2.27.0
[PATCH v2 4/4] powercap: Add AMD Fam19h RAPL support
AMD Family 19h's RAPL MSRs are identical to Family 17h's. Extend
Family 17h's support to Family 19h.
Signed-off-by: Kim Phillips
Cc: Victor Ding
Cc: Alexander Shishkin
Cc: Borislav Petkov
Cc: Daniel Lezcano
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Pawan Gupta
Cc: "Peter Zijlstra (Intel)"
Cc: "Rafael J. Wysocki"
Cc: Sean Christopherson
Cc: Thomas Gleixner
Cc: Tony Luck
Cc: Vineela Tummalapalli
Cc: LKML
Cc: linux...@vger.kernel.org
Cc: x...@kernel.org
---
Change from the original submission:
https://lore.kernel.org/patchwork/patch/1289843/
- Added Daniel Lezcano to Cc.
drivers/powercap/intel_rapl_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/intel_rapl_common.c
b/drivers/powercap/intel_rapl_common.c
index 6905ccffcec3..56894f4cd394 100644
--- a/drivers/powercap/intel_rapl_common.c
+++ b/drivers/powercap/intel_rapl_common.c
@@ -1056,6 +1056,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,
_defaults_hsw_server),
X86_MATCH_VENDOR_FAM(AMD, 0x17, _defaults_core),
+ X86_MATCH_VENDOR_FAM(AMD, 0x19, _defaults_core),
{}
};
MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
--
2.27.0
[PATCH v2 1/4] x86/msr-index: sort AMD RAPL MSRs by address
From: Victor Ding MSRs in the rest of this file are sorted by their addresses; fixing the two outliers. No functional changes. Signed-off-by: Victor Ding Acked-by: Kim Phillips Cc: Victor Ding Cc: Alexander Shishkin Cc: Borislav Petkov Cc: Daniel Lezcano Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Pawan Gupta Cc: "Peter Zijlstra (Intel)" Cc: "Rafael J. Wysocki" Cc: Sean Christopherson Cc: Thomas Gleixner Cc: Tony Luck Cc: Vineela Tummalapalli Cc: LKML Cc: linux...@vger.kernel.org Cc: x...@kernel.org --- Kim's changes from Victor's original submission: https://lore.kernel.org/lkml/20200729205144.1.I8556c0b9b6f75bf3121989f5641c33e694fff8d9@changeid/ - Added my Acked-by. - Added Daniel Lezcano to Cc. arch/x86/include/asm/msr-index.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 2859ee4f39a8..f1b24f1b774d 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -323,8 +323,8 @@ #define MSR_PP1_ENERGY_STATUS 0x0641 #define MSR_PP1_POLICY 0x0642 -#define MSR_AMD_PKG_ENERGY_STATUS 0xc001029b #define MSR_AMD_RAPL_POWER_UNIT0xc0010299 +#define MSR_AMD_PKG_ENERGY_STATUS 0xc001029b /* Config TDP MSRs */ #define MSR_CONFIG_TDP_NOMINAL 0x0648 -- 2.27.0
Re: [PATCH] perf/x86/intel: Fix n_metric for the canceled group
On 10/2/20 8:16 AM, Liang, Kan wrote:
> On 10/2/2020 7:02 AM, Peter Zijlstra wrote:
>> On Wed, Sep 30, 2020 at 07:29:35AM -0700, kan.li...@linux.intel.com wrote:
>>> From: Kan Liang
>>>
>>> When a group that has TopDown members is failed to be scheduled, any
>>> later TopDown groups will not return valid values.
>>>
>>> Here is an example.
>>>
>>> A background perf that occupies all the GP counters and the fixed
>>> counter 1.
>>> $perf stat -e "{cycles,cycles,cycles,cycles,cycles,cycles,cycles,
>>> cycles,cycles}:D" -a
>>>
>>> A user monitors a TopDown group. It works well, because the fixed
>>> counter 3 and the PERF_METRICS are available.
>>> $perf stat -x, --topdown -- ./workload
>>> retiring,bad speculation,frontend bound,backend bound,
>>> 18.0,16.1,40.4,25.5,
>>>
>>> Then the user tries to monitor a group that has TopDown members.
>>> Because of the cycles event, the group is failed to be scheduled.
>>> $perf stat -x, -e '{slots,topdown-retiring,topdown-be-bound,
>>> topdown-fe-bound,topdown-bad-spec,cycles}'
>>> -- ./workload
>>> ,,slots,0,0.00,,
>>> ,,topdown-retiring,0,0.00,,
>>> ,,topdown-be-bound,0,0.00,,
>>> ,,topdown-fe-bound,0,0.00,,
>>> ,,topdown-bad-spec,0,0.00,,
>>> ,,cycles,0,0.00,,
>>>
>>> The user tries to monitor a TopDown group again. It doesn't work anymore.
>>> $perf stat -x, --topdown -- ./workload
>>>
>>> ,
>>>
>>> In a txn, cancel_txn() is to truncate the event_list for a canceled
>>> group and update the number of events added in this transaction.
>>> However, the number of TopDown events added in this transaction is not
>>> updated. The kernel will probably fail to add new Topdown events.
>>>
>>> Check if the canceled group has Topdown events. If so, subtract the
>>> TopDown events from n_metric accordingly.
>>>
>>> Fixes: 7b2c05a15d29 ("perf/x86/intel: Generic support for hardware TopDown
>>> metrics")
>>> Reported-by: Andi Kleen
>>> Reviewed-by: Andi Kleen
>>> Signed-off-by: Kan Liang
>>> ---
>>
>> Urgh, I'd much rather we add n_txn_metric. But also, while looking at
>> this, don't we have the same problem with n_pair ?
>>
>> Something like this perhaps...
>>
>
> Sure. For the perf metric, the below patch fixes the problem.
>
> Tested-by: Kan Liang
Tested-by: Kim Phillips
Excerpt from test script:
sudo perf stat -e "{cycles,cycles,cycles,cycles}:D" -a sleep 10 &
# should succeed:
sudo perf stat -e "{fp_ret_sse_avx_ops.all}:D" -a workload
# should fail:
sudo perf stat -e "{fp_ret_sse_avx_ops.all,fp_ret_sse_avx_ops.all,cycles}:D" -a
workload
# previously failed, now succeeds with this patch:
sudo perf stat -e "{fp_ret_sse_avx_ops.all}:D" -a workload
Thanks both,
Kim
Re: [PATCH] rcu,ftrace: Fix ftrace recursion
On 9/29/20 6:33 AM, Peter Zijlstra wrote:
>
> Kim reported that perf-ftrace made his box unhappy. It turns out that
> commit:
>
> ff5c4f5cad33 ("rcu/tree: Mark the idle relevant functions noinstr")
>
> removed one too many notrace. Probably due to there not being a helpful
> comment.
>
> Reinstate the notrace and add a comment to avoid loosing it again.
>
> Fixes: ff5c4f5cad33 ("rcu/tree: Mark the idle relevant functions noinstr")
> Reported-by: Kim Phillips
> Signed-off-by: Peter Zijlstra (Intel)
> ---
Tested-by: Kim Phillips
Thanks,
Kim
Re: [tip: core/rcu] rcu/tree: Mark the idle relevant functions noinstr
Hi,
On 5/19/20 2:52 PM, tip-bot2 for Thomas Gleixner wrote:
> The following commit has been merged into the core/rcu branch of tip:
>
> Commit-ID: ff5c4f5cad33061b07c3fb9187506783c0f3cb66
> Gitweb:
> https://git.kernel.org/tip/ff5c4f5cad33061b07c3fb9187506783c0f3cb66
> Author:Thomas Gleixner
> AuthorDate:Fri, 13 Mar 2020 17:32:17 +01:00
> Committer: Thomas Gleixner
> CommitterDate: Tue, 19 May 2020 15:51:20 +02:00
>
> rcu/tree: Mark the idle relevant functions noinstr
>
> These functions are invoked from context tracking and other places in the
> low level entry code. Move them into the .noinstr.text section to exclude
> them from instrumentation.
>
> Mark the places which are safe to invoke traceable functions with
> instrumentation_begin/end() so objtool won't complain.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Alexandre Chartre
> Acked-by: Peter Zijlstra
> Acked-by: Paul E. McKenney
> Link: https://lkml.kernel.org/r/20200505134100.575356...@linutronix.de
>
>
> ---
I bisected a system hang condition down to this commit.
To reproduce the hang, compile the below code and execute it as root
on an x86_64 server (AMD or Intel). The code is opening a
PERF_TYPE_TRACEPOINT event with a non-zero pe.config.
If I revert the commit from Linus' ToT, the system stays up.
.config attached.
Thanks,
Kim
#include
#include
#include
#include
#include
#include
#include
static long
perf_event_open(struct perf_event_attr *hw_event, pid_t pid,
int cpu, int group_fd, unsigned long flags)
{
int ret;
ret = syscall(__NR_perf_event_open, hw_event, pid, cpu,
group_fd, flags);
return ret;
}
int
main(int argc, char **argv)
{
struct perf_event_attr pe;
long long count;
int fd;
memset(, 0, sizeof(struct perf_event_attr));
pe.type = PERF_TYPE_TRACEPOINT;
pe.size = sizeof(struct perf_event_attr);
pe.config = PERF_COUNT_HW_INSTRUCTIONS;
pe.disabled = 1;
pe.exclude_kernel = 1;
pe.exclude_hv = 1;
fd = perf_event_open(, 0, -1, -1, 0);
if (fd == -1) {
fprintf(stderr, "Error opening leader %llx\n", pe.config);
exit(EXIT_FAILURE);
}
}
config.xz
Description: application/xz
[tip: perf/core] perf/amd/uncore: Inform the user how many counters each uncore PMU has
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 9ed9647dc0671486f9e998b7258f75167a9c4697
Gitweb:
https://git.kernel.org/tip/9ed9647dc0671486f9e998b7258f75167a9c4697
Author:Kim Phillips
AuthorDate:Mon, 21 Sep 2020 09:43:30 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 24 Sep 2020 15:55:50 +02:00
perf/amd/uncore: Inform the user how many counters each uncore PMU has
Previously, the uncore driver would say "NB counters detected" on F17h
machines, which don't have NorthBridge (NB) counters. They have Data
Fabric (DF) counters. Just use the pmu.name to inform users which pmu
to use and its associated counter count.
F17h dmesg BEFORE:
amd_uncore: AMD NB counters detected
amd_uncore: AMD LLC counters detected
F17h dmesg AFTER:
amd_uncore: 4 amd_df counters detected
amd_uncore: 6 amd_l3 counters detected
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200921144330.6331-5-kim.phill...@amd.com
---
arch/x86/events/amd/uncore.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index f026715..7f014d4 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -595,9 +595,10 @@ static int __init amd_uncore_init(void)
if (ret)
goto fail_nb;
- pr_info("%s NB counters detected\n",
- boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ?
- "HYGON" : "AMD");
+ pr_info("%d %s %s counters detected\n", num_counters_nb,
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ? "HYGON"
: "",
+ amd_nb_pmu.name);
+
ret = 0;
}
@@ -626,9 +627,9 @@ static int __init amd_uncore_init(void)
if (ret)
goto fail_llc;
- pr_info("%s LLC counters detected\n",
- boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ?
- "HYGON" : "AMD");
+ pr_info("%d %s %s counters detected\n", num_counters_llc,
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ? "HYGON"
: "",
+ amd_llc_pmu.name);
ret = 0;
}
[tip: perf/core] perf/amd/uncore: Allow F19h user coreid, threadmask, and sliceid specification
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 87a54a1fd525f2af8d82becf583c7e836918cf22
Gitweb:
https://git.kernel.org/tip/87a54a1fd525f2af8d82becf583c7e836918cf22
Author:Kim Phillips
AuthorDate:Mon, 21 Sep 2020 09:43:29 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 24 Sep 2020 15:55:50 +02:00
perf/amd/uncore: Allow F19h user coreid, threadmask, and sliceid specification
On Family 19h, the driver checks for a populated 2-bit threadmask in
order to establish that the user wants to measure individual slices,
individual cores (only one can be measured at a time), and lets
the user also directly specify enallcores and/or enallslices if
desired.
Example F19h invocation to measure L3 accesses (event 4, umask 0xff)
by the first thread (id 0 -> mask 0x1) of the first core (id 0) on the
first slice (id 0):
perf stat -a -e
instructions,amd_l3/umask=0xff,event=0x4,coreid=0,threadmask=1,sliceid=0,enallcores=0,enallslices=0/
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200921144330.6331-4-kim.phill...@amd.com
---
arch/x86/events/amd/uncore.c | 37 ++-
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 1e35c93..f026715 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -190,8 +190,19 @@ static u64 l3_thread_slice_mask(u64 config)
return ((config & AMD64_L3_SLICE_MASK) ? : AMD64_L3_SLICE_MASK)
|
((config & AMD64_L3_THREAD_MASK) ? :
AMD64_L3_THREAD_MASK);
- return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
- AMD64_L3_F19H_THREAD_MASK;
+ /*
+* If the user doesn't specify a threadmask, they're not trying to
+* count core 0, so we enable all cores & threads.
+* We'll also assume that they want to count slice 0 if they specify
+* a threadmask and leave sliceid and enallslices unpopulated.
+*/
+ if (!(config & AMD64_L3_F19H_THREAD_MASK))
+ return AMD64_L3_F19H_THREAD_MASK | AMD64_L3_EN_ALL_SLICES |
+ AMD64_L3_EN_ALL_CORES;
+
+ return config & (AMD64_L3_F19H_THREAD_MASK | AMD64_L3_SLICEID_MASK |
+AMD64_L3_EN_ALL_CORES | AMD64_L3_EN_ALL_SLICES |
+AMD64_L3_COREID_MASK);
}
static int amd_uncore_event_init(struct perf_event *event)
@@ -278,8 +289,13 @@ DEFINE_UNCORE_FORMAT_ATTR(event12, event,
"config:0-7,32-35");
DEFINE_UNCORE_FORMAT_ATTR(event14, event,
"config:0-7,32-35,59-60"); /* F17h+ DF */
DEFINE_UNCORE_FORMAT_ATTR(event8, event, "config:0-7");
/* F17h+ L3 */
DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
+DEFINE_UNCORE_FORMAT_ATTR(coreid, coreid, "config:42-44");
/* F19h L3 */
DEFINE_UNCORE_FORMAT_ATTR(slicemask, slicemask, "config:48-51");
/* F17h L3 */
DEFINE_UNCORE_FORMAT_ATTR(threadmask8, threadmask, "config:56-63");
/* F17h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(threadmask2, threadmask, "config:56-57");
/* F19h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(enallslices, enallslices,"config:46");
/* F19h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(enallcores, enallcores, "config:47");
/* F19h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(sliceid, sliceid,"config:48-50");
/* F19h L3 */
static struct attribute *amd_uncore_df_format_attr[] = {
_attr_event12.attr, /* event14 if F17h+ */
@@ -290,8 +306,11 @@ static struct attribute *amd_uncore_df_format_attr[] = {
static struct attribute *amd_uncore_l3_format_attr[] = {
_attr_event12.attr, /* event8 if F17h+ */
_attr_umask.attr,
- NULL, /* slicemask if F17h */
- NULL, /* threadmask8 if F17h */
+ NULL, /* slicemask if F17h, coreid if F19h */
+ NULL, /* threadmask8 if F17h, enallslices if F19h */
+ NULL, /*enallcores if F19h */
+ NULL, /*sliceid if F19h */
+ NULL, /*threadmask2 if F19h */
NULL,
};
@@ -583,7 +602,15 @@ static int __init amd_uncore_init(void)
}
if (boot_cpu_has(X86_FEATURE_PERFCTR_LLC)) {
- if (boot_cpu_data.x86 >= 0x17) {
+ if (boot_cpu_data.x86 >= 0x19) {
+ *l3_attr++ = _attr_event8.attr;
+ *l3_attr++ = _attr_umask.attr;
+ *l3_attr++ = _attr_coreid.attr;
+ *l3_attr++ = _attr_enallslices.attr;
+ *l3_attr++ = _attr_enallcores.attr;
+ *l3_att
[tip: perf/core] perf/amd/uncore: Allow F17h user threadmask and slicemask specification
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 8170f386f19ca7120393c957d4bfbdc07f964ab6
Gitweb:
https://git.kernel.org/tip/8170f386f19ca7120393c957d4bfbdc07f964ab6
Author:Kim Phillips
AuthorDate:Mon, 21 Sep 2020 09:43:28 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 24 Sep 2020 15:55:49 +02:00
perf/amd/uncore: Allow F17h user threadmask and slicemask specification
Continue to fully populate either one of threadmask or slicemask if the
user doesn't.
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200921144330.6331-3-kim.phill...@amd.com
---
arch/x86/events/amd/uncore.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 15c7982..1e35c93 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -181,13 +181,14 @@ static void amd_uncore_del(struct perf_event *event, int
flags)
}
/*
- * Return a full thread and slice mask until per-CPU is
- * properly supported.
+ * Return a full thread and slice mask unless user
+ * has provided them
*/
-static u64 l3_thread_slice_mask(void)
+static u64 l3_thread_slice_mask(u64 config)
{
if (boot_cpu_data.x86 <= 0x18)
- return AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK;
+ return ((config & AMD64_L3_SLICE_MASK) ? : AMD64_L3_SLICE_MASK)
|
+ ((config & AMD64_L3_THREAD_MASK) ? :
AMD64_L3_THREAD_MASK);
return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
AMD64_L3_F19H_THREAD_MASK;
@@ -220,7 +221,7 @@ static int amd_uncore_event_init(struct perf_event *event)
* For other events, the two fields do not affect the count.
*/
if (l3_mask && is_llc_event(event))
- hwc->config |= l3_thread_slice_mask();
+ hwc->config |= l3_thread_slice_mask(event->attr.config);
uncore = event_to_amd_uncore(event);
if (!uncore)
@@ -277,6 +278,8 @@ DEFINE_UNCORE_FORMAT_ATTR(event12, event,
"config:0-7,32-35");
DEFINE_UNCORE_FORMAT_ATTR(event14, event,
"config:0-7,32-35,59-60"); /* F17h+ DF */
DEFINE_UNCORE_FORMAT_ATTR(event8, event, "config:0-7");
/* F17h+ L3 */
DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
+DEFINE_UNCORE_FORMAT_ATTR(slicemask, slicemask, "config:48-51");
/* F17h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(threadmask8, threadmask, "config:56-63");
/* F17h L3 */
static struct attribute *amd_uncore_df_format_attr[] = {
_attr_event12.attr, /* event14 if F17h+ */
@@ -287,6 +290,8 @@ static struct attribute *amd_uncore_df_format_attr[] = {
static struct attribute *amd_uncore_l3_format_attr[] = {
_attr_event12.attr, /* event8 if F17h+ */
_attr_umask.attr,
+ NULL, /* slicemask if F17h */
+ NULL, /* threadmask8 if F17h */
NULL,
};
@@ -578,8 +583,12 @@ static int __init amd_uncore_init(void)
}
if (boot_cpu_has(X86_FEATURE_PERFCTR_LLC)) {
- if (boot_cpu_data.x86 >= 0x17)
- *l3_attr = _attr_event8.attr;
+ if (boot_cpu_data.x86 >= 0x17) {
+ *l3_attr++ = _attr_event8.attr;
+ *l3_attr++ = _attr_umask.attr;
+ *l3_attr++ = _attr_slicemask.attr;
+ *l3_attr++ = _attr_threadmask8.attr;
+ }
amd_uncore_llc = alloc_percpu(struct amd_uncore *);
if (!amd_uncore_llc) {
[tip: perf/core] perf/amd/uncore: Prepare to scale for more attributes that vary per family
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 06f2c24584f31bc16129643bfb8239a1af82a17f
Gitweb:
https://git.kernel.org/tip/06f2c24584f31bc16129643bfb8239a1af82a17f
Author:Kim Phillips
AuthorDate:Mon, 21 Sep 2020 09:43:27 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 24 Sep 2020 15:55:49 +02:00
perf/amd/uncore: Prepare to scale for more attributes that vary per family
Replace AMD_FORMAT_ATTR with the more apropos DEFINE_UNCORE_FORMAT_ATTR
stolen from arch/x86/events/intel/uncore.h. This way we can clearly
see the bit-variants of each of the attributes that want to have
the same name across families.
Also unroll AMD_ATTRIBUTE because we are going to separately add
new attributes that differ between DF and L3.
Also clean up the if-Family 17h-else logic in amd_uncore_init.
This is basically a rewrite of commit da6adaea2b7e
("perf/x86/amd/uncore: Update sysfs attributes for Family17h processors").
No functional changes.
Tested F17h+ /sys/bus/event_source/devices/amd_{l3,df}/format/*
content remains unchanged:
/sys/bus/event_source/devices/amd_l3/format/event:config:0-7
/sys/bus/event_source/devices/amd_l3/format/umask:config:8-15
/sys/bus/event_source/devices/amd_df/format/event:config:0-7,32-35,59-60
/sys/bus/event_source/devices/amd_df/format/umask:config:8-15
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200921144330.6331-2-kim.phill...@amd.com
---
arch/x86/events/amd/uncore.c | 111 ++
1 file changed, 61 insertions(+), 50 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index e7e61c8..15c7982 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -262,47 +262,60 @@ static struct attribute_group amd_uncore_attr_group = {
.attrs = amd_uncore_attrs,
};
-/*
- * Similar to PMU_FORMAT_ATTR but allowing for format_attr to be assigned based
- * on family
- */
-#define AMD_FORMAT_ATTR(_dev, _name, _format) \
-static ssize_t \
-_dev##_show##_name(struct device *dev, \
- struct device_attribute *attr, \
- char *page) \
-{ \
- BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
- return sprintf(page, _format "\n"); \
-} \
-static struct device_attribute format_attr_##_dev##_name = __ATTR_RO(_dev);
-
-/* Used for each uncore counter type */
-#define AMD_ATTRIBUTE(_name)\
-static struct attribute *amd_uncore_format_attr_##_name[] = { \
- _attr_event_##_name.attr, \
- _attr_umask.attr, \
- NULL,\
-}; \
-static struct attribute_group amd_uncore_format_group_##_name = { \
- .name = "format",\
- .attrs = amd_uncore_format_attr_##_name, \
-}; \
-static const struct attribute_group *amd_uncore_attr_groups_##_name[] = {\
- _uncore_attr_group, \
- _uncore_format_group_##_name,\
- NULL,\
+#define DEFINE_UNCORE_FORMAT_ATTR(_var, _name, _format)
\
+static ssize_t __uncore_##_var##_show(struct kobject *kobj,\
+ struct kobj_attribute *attr,\
+ char *page) \
+{ \
+ BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
+ return sprintf(page, _format "\n"); \
+} \
+static struct kobj_attribute format_attr_##_var = \
+ __ATTR(_name, 0444, __uncore_##_var##_show, NULL)
+
+DEFINE_UNCORE_FORMAT_ATTR(event12, event, "config:0-7,32-35");
+DEFINE_UNCORE_FORMAT_ATTR(event14, event,
"config:0-7,32-35,59-60"); /* F17h+ DF */
+DEFINE_UNCORE_FORMAT_ATTR(event8, event, "config:0-7"
[PATCH 4/4] perf/amd/uncore: Inform the user how many counters each uncore PMU has
Previously, the uncore driver would say "NB counters detected" on F17h
machines, which don't have NorthBridge (NB) counters. They have Data
Fabric (DF) counters. Just use the pmu.name to inform users which pmu
to use and its associated counter count.
F17h dmesg BEFORE:
amd_uncore: AMD NB counters detected
amd_uncore: AMD LLC counters detected
F17h dmesg AFTER:
amd_uncore: 4 amd_df counters detected
amd_uncore: 6 amd_l3 counters detected
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/events/amd/uncore.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index f026715a39d2..7f014d450bc2 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -595,9 +595,10 @@ static int __init amd_uncore_init(void)
if (ret)
goto fail_nb;
- pr_info("%s NB counters detected\n",
- boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ?
- "HYGON" : "AMD");
+ pr_info("%d %s %s counters detected\n", num_counters_nb,
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ? "HYGON"
: "",
+ amd_nb_pmu.name);
+
ret = 0;
}
@@ -626,9 +627,9 @@ static int __init amd_uncore_init(void)
if (ret)
goto fail_llc;
- pr_info("%s LLC counters detected\n",
- boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ?
- "HYGON" : "AMD");
+ pr_info("%d %s %s counters detected\n", num_counters_llc,
+ boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ? "HYGON"
: "",
+ amd_llc_pmu.name);
ret = 0;
}
--
2.27.0
[PATCH 0/4] perf/amd/uncore: Support user core/thread and slice specification
Add support for AMD's uncore L3 PMUs to count events by core/thread and/or by L3 slice. The first patch rewrites most of the initial F17h support to enhance readability and to prepare for the new upcoming attributes. The second patch adds support for F17h's threadmask and slicemask. The third patch adds support for F19h's threadmask, coreid, sliceid, enallcores, and enallslices. F19h hardware can only count one core or slice, or all of them at one time. The last patch makes the driver's dmesg output more useful. Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: x...@kernel.org Cc: linux-kernel@vger.kernel.org Kim Phillips (4): perf/amd/uncore: Prepare to scale for more attributes that vary per family perf/amd/uncore: Allow F17h user threadmask and slicemask specification perf/amd/uncore: Allow F19h user coreid, threadmask, and sliceid specification perf/amd/uncore: Inform the user how many counters each uncore PMU has arch/x86/events/amd/uncore.c | 174 ++- 1 file changed, 111 insertions(+), 63 deletions(-) -- 2.27.0
[PATCH 3/4] perf/amd/uncore: Allow F19h user coreid, threadmask, and sliceid specification
On Family 19h, the driver checks for a populated 2-bit threadmask in
order to establish that the user wants to measure individual slices,
individual cores (only one can be measured at a time), and lets
the user also directly specify enallcores and/or enallslices if
desired.
Example F19h invocation to measure L3 accesses (event 4, umask 0xff)
by the first thread (id 0 -> mask 0x1) of the first core (id 0) on the
first slice (id 0):
perf stat -a -e
instructions,amd_l3/umask=0xff,event=0x4,coreid=0,threadmask=1,sliceid=0,enallcores=0,enallslices=0/
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/events/amd/uncore.c | 37 +++-
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 1e35c934fe7c..f026715a39d2 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -190,8 +190,19 @@ static u64 l3_thread_slice_mask(u64 config)
return ((config & AMD64_L3_SLICE_MASK) ? : AMD64_L3_SLICE_MASK)
|
((config & AMD64_L3_THREAD_MASK) ? :
AMD64_L3_THREAD_MASK);
- return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
- AMD64_L3_F19H_THREAD_MASK;
+ /*
+* If the user doesn't specify a threadmask, they're not trying to
+* count core 0, so we enable all cores & threads.
+* We'll also assume that they want to count slice 0 if they specify
+* a threadmask and leave sliceid and enallslices unpopulated.
+*/
+ if (!(config & AMD64_L3_F19H_THREAD_MASK))
+ return AMD64_L3_F19H_THREAD_MASK | AMD64_L3_EN_ALL_SLICES |
+ AMD64_L3_EN_ALL_CORES;
+
+ return config & (AMD64_L3_F19H_THREAD_MASK | AMD64_L3_SLICEID_MASK |
+AMD64_L3_EN_ALL_CORES | AMD64_L3_EN_ALL_SLICES |
+AMD64_L3_COREID_MASK);
}
static int amd_uncore_event_init(struct perf_event *event)
@@ -278,8 +289,13 @@ DEFINE_UNCORE_FORMAT_ATTR(event12, event,
"config:0-7,32-35");
DEFINE_UNCORE_FORMAT_ATTR(event14, event,
"config:0-7,32-35,59-60"); /* F17h+ DF */
DEFINE_UNCORE_FORMAT_ATTR(event8, event, "config:0-7");
/* F17h+ L3 */
DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
+DEFINE_UNCORE_FORMAT_ATTR(coreid, coreid, "config:42-44");
/* F19h L3 */
DEFINE_UNCORE_FORMAT_ATTR(slicemask, slicemask, "config:48-51");
/* F17h L3 */
DEFINE_UNCORE_FORMAT_ATTR(threadmask8, threadmask, "config:56-63");
/* F17h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(threadmask2, threadmask, "config:56-57");
/* F19h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(enallslices, enallslices,"config:46");
/* F19h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(enallcores, enallcores, "config:47");
/* F19h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(sliceid, sliceid,"config:48-50");
/* F19h L3 */
static struct attribute *amd_uncore_df_format_attr[] = {
_attr_event12.attr, /* event14 if F17h+ */
@@ -290,8 +306,11 @@ static struct attribute *amd_uncore_df_format_attr[] = {
static struct attribute *amd_uncore_l3_format_attr[] = {
_attr_event12.attr, /* event8 if F17h+ */
_attr_umask.attr,
- NULL, /* slicemask if F17h */
- NULL, /* threadmask8 if F17h */
+ NULL, /* slicemask if F17h, coreid if F19h */
+ NULL, /* threadmask8 if F17h, enallslices if F19h */
+ NULL, /*enallcores if F19h */
+ NULL, /*sliceid if F19h */
+ NULL, /*threadmask2 if F19h */
NULL,
};
@@ -583,7 +602,15 @@ static int __init amd_uncore_init(void)
}
if (boot_cpu_has(X86_FEATURE_PERFCTR_LLC)) {
- if (boot_cpu_data.x86 >= 0x17) {
+ if (boot_cpu_data.x86 >= 0x19) {
+ *l3_attr++ = _attr_event8.attr;
+ *l3_attr++ = _attr_umask.attr;
+ *l3_attr++ = _attr_coreid.attr;
+ *l3_attr++ = _attr_enallslices.attr;
+ *l3_attr++ = _attr_enallcores.attr;
+ *l3_attr++ = _attr_sliceid.attr;
+ *l3_attr++ = _attr_threadmask2.attr;
+ } else if (boot_cpu_data.x86 >= 0x17) {
*l3_attr++ = _attr_event8.attr;
*l3_attr++ = _attr_umask.attr;
*l3_attr++ = _attr_slicemask.attr;
--
2.27.0
[PATCH 2/4] perf/amd/uncore: Allow F17h user threadmask and slicemask specification
Continue to fully populate either one of threadmask or slicemask if the
user doesn't.
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/events/amd/uncore.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 15c7982b1c58..1e35c934fe7c 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -181,13 +181,14 @@ static void amd_uncore_del(struct perf_event *event, int
flags)
}
/*
- * Return a full thread and slice mask until per-CPU is
- * properly supported.
+ * Return a full thread and slice mask unless user
+ * has provided them
*/
-static u64 l3_thread_slice_mask(void)
+static u64 l3_thread_slice_mask(u64 config)
{
if (boot_cpu_data.x86 <= 0x18)
- return AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK;
+ return ((config & AMD64_L3_SLICE_MASK) ? : AMD64_L3_SLICE_MASK)
|
+ ((config & AMD64_L3_THREAD_MASK) ? :
AMD64_L3_THREAD_MASK);
return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
AMD64_L3_F19H_THREAD_MASK;
@@ -220,7 +221,7 @@ static int amd_uncore_event_init(struct perf_event *event)
* For other events, the two fields do not affect the count.
*/
if (l3_mask && is_llc_event(event))
- hwc->config |= l3_thread_slice_mask();
+ hwc->config |= l3_thread_slice_mask(event->attr.config);
uncore = event_to_amd_uncore(event);
if (!uncore)
@@ -277,6 +278,8 @@ DEFINE_UNCORE_FORMAT_ATTR(event12, event,
"config:0-7,32-35");
DEFINE_UNCORE_FORMAT_ATTR(event14, event,
"config:0-7,32-35,59-60"); /* F17h+ DF */
DEFINE_UNCORE_FORMAT_ATTR(event8, event, "config:0-7");
/* F17h+ L3 */
DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
+DEFINE_UNCORE_FORMAT_ATTR(slicemask, slicemask, "config:48-51");
/* F17h L3 */
+DEFINE_UNCORE_FORMAT_ATTR(threadmask8, threadmask, "config:56-63");
/* F17h L3 */
static struct attribute *amd_uncore_df_format_attr[] = {
_attr_event12.attr, /* event14 if F17h+ */
@@ -287,6 +290,8 @@ static struct attribute *amd_uncore_df_format_attr[] = {
static struct attribute *amd_uncore_l3_format_attr[] = {
_attr_event12.attr, /* event8 if F17h+ */
_attr_umask.attr,
+ NULL, /* slicemask if F17h */
+ NULL, /* threadmask8 if F17h */
NULL,
};
@@ -578,8 +583,12 @@ static int __init amd_uncore_init(void)
}
if (boot_cpu_has(X86_FEATURE_PERFCTR_LLC)) {
- if (boot_cpu_data.x86 >= 0x17)
- *l3_attr = _attr_event8.attr;
+ if (boot_cpu_data.x86 >= 0x17) {
+ *l3_attr++ = _attr_event8.attr;
+ *l3_attr++ = _attr_umask.attr;
+ *l3_attr++ = _attr_slicemask.attr;
+ *l3_attr++ = _attr_threadmask8.attr;
+ }
amd_uncore_llc = alloc_percpu(struct amd_uncore *);
if (!amd_uncore_llc) {
--
2.27.0
[PATCH 1/4] perf/amd/uncore: Prepare to scale for more attributes that vary per family
Replace AMD_FORMAT_ATTR with the more apropos DEFINE_UNCORE_FORMAT_ATTR
stolen from arch/x86/events/intel/uncore.h. This way we can clearly
see the bit-variants of each of the attributes that want to have
the same name across families.
Also unroll AMD_ATTRIBUTE because we are going to separately add
new attributes that differ between DF and L3.
Also clean up the if-Family 17h-else logic in amd_uncore_init.
This is basically a rewrite of commit da6adaea2b7e
("perf/x86/amd/uncore: Update sysfs attributes for Family17h processors").
No functional changes.
Tested F17h+ /sys/bus/event_source/devices/amd_{l3,df}/format/*
content remains unchanged:
/sys/bus/event_source/devices/amd_l3/format/event:config:0-7
/sys/bus/event_source/devices/amd_l3/format/umask:config:8-15
/sys/bus/event_source/devices/amd_df/format/event:config:0-7,32-35,59-60
/sys/bus/event_source/devices/amd_df/format/umask:config:8-15
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/events/amd/uncore.c | 111 +++
1 file changed, 61 insertions(+), 50 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index e7e61c8b56bd..15c7982b1c58 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -262,47 +262,60 @@ static struct attribute_group amd_uncore_attr_group = {
.attrs = amd_uncore_attrs,
};
-/*
- * Similar to PMU_FORMAT_ATTR but allowing for format_attr to be assigned based
- * on family
- */
-#define AMD_FORMAT_ATTR(_dev, _name, _format) \
-static ssize_t \
-_dev##_show##_name(struct device *dev, \
- struct device_attribute *attr, \
- char *page) \
-{ \
- BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
- return sprintf(page, _format "\n"); \
-} \
-static struct device_attribute format_attr_##_dev##_name = __ATTR_RO(_dev);
-
-/* Used for each uncore counter type */
-#define AMD_ATTRIBUTE(_name)\
-static struct attribute *amd_uncore_format_attr_##_name[] = { \
- _attr_event_##_name.attr, \
- _attr_umask.attr, \
- NULL,\
-}; \
-static struct attribute_group amd_uncore_format_group_##_name = { \
- .name = "format",\
- .attrs = amd_uncore_format_attr_##_name, \
-}; \
-static const struct attribute_group *amd_uncore_attr_groups_##_name[] = {\
- _uncore_attr_group, \
- _uncore_format_group_##_name,\
- NULL,\
+#define DEFINE_UNCORE_FORMAT_ATTR(_var, _name, _format)
\
+static ssize_t __uncore_##_var##_show(struct kobject *kobj,\
+ struct kobj_attribute *attr,\
+ char *page) \
+{ \
+ BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
+ return sprintf(page, _format "\n"); \
+} \
+static struct kobj_attribute format_attr_##_var = \
+ __ATTR(_name, 0444, __uncore_##_var##_show, NULL)
+
+DEFINE_UNCORE_FORMAT_ATTR(event12, event, "config:0-7,32-35");
+DEFINE_UNCORE_FORMAT_ATTR(event14, event,
"config:0-7,32-35,59-60"); /* F17h+ DF */
+DEFINE_UNCORE_FORMAT_ATTR(event8, event, "config:0-7");
/* F17h+ L3 */
+DEFINE_UNCORE_FORMAT_ATTR(umask, umask, "config:8-15");
+
+static struct attribute *amd_uncore_df_format_attr[] = {
+ _attr_event12.attr, /* event14 if F17h+ */
+
Re: [PATCH v2] perf vendor events amd: remove trailing commas
On 9/14/20 9:49 PM, Namhyung Kim wrote: > On Tue, Sep 15, 2020 at 9:41 AM Henry Burns wrote: >> >> amdzen2/core.json and amdzen/core.json have the occasional trailing >> comma. Since that goes against the JSON standard, lets remove it. >> >> Signed-off-by: Henry Burns > > Acked-by: Namhyung Kim Acked-by: Kim Phillips Thanks, Kim
[tip: perf/core] perf/x86/amd/ibs: Fix raw sample data accumulation
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 36e1be8ada994d509538b3b1d0af8b63c351e729
Gitweb:
https://git.kernel.org/tip/36e1be8ada994d509538b3b1d0af8b63c351e729
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:38 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:35 +02:00
perf/x86/amd/ibs: Fix raw sample data accumulation
Neither IbsBrTarget nor OPDATA4 are populated in IBS Fetch mode.
Don't accumulate them into raw sample user data in that case.
Also, in Fetch mode, add saving the IBS Fetch Control Extended MSR.
Technically, there is an ABI change here with respect to the IBS raw
sample data format, but I don't see any perf driver version information
being included in perf.data file headers, but, existing users can detect
whether the size of the sample record has reduced by 8 bytes to
determine whether the IBS driver has this fix.
Fixes: 904cb3677f3a ("perf/x86/amd/ibs: Update IBS MSRs and feature
definitions")
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20200908214740.18097-6-kim.phill...@amd.com
---
arch/x86/events/amd/ibs.c| 26 --
arch/x86/include/asm/msr-index.h | 1 +
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 863174a..cfbd020 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -630,18 +630,24 @@ fail:
perf_ibs->offset_max,
offset + 1);
} while (offset < offset_max);
+ /*
+* Read IbsBrTarget, IbsOpData4, and IbsExtdCtl separately
+* depending on their availability.
+* Can't add to offset_max as they are staggered
+*/
if (event->attr.sample_type & PERF_SAMPLE_RAW) {
- /*
-* Read IbsBrTarget and IbsOpData4 separately
-* depending on their availability.
-* Can't add to offset_max as they are staggered
-*/
- if (ibs_caps & IBS_CAPS_BRNTRGT) {
- rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++);
- size++;
+ if (perf_ibs == _ibs_op) {
+ if (ibs_caps & IBS_CAPS_BRNTRGT) {
+ rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++);
+ size++;
+ }
+ if (ibs_caps & IBS_CAPS_OPDATA4) {
+ rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++);
+ size++;
+ }
}
- if (ibs_caps & IBS_CAPS_OPDATA4) {
- rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++);
+ if (perf_ibs == _ibs_fetch && (ibs_caps &
IBS_CAPS_FETCHCTLEXTD)) {
+ rdmsrl(MSR_AMD64_ICIBSEXTDCTL, *buf++);
size++;
}
}
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index dc131b8..2d39c31 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -464,6 +464,7 @@
#define MSR_AMD64_IBSOP_REG_MASK ((1UL<
[tip: perf/core] perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 8b0bed7d410f48499d72af2e2bcd890daad94e0d
Gitweb:
https://git.kernel.org/tip/8b0bed7d410f48499d72af2e2bcd890daad94e0d
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:39 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:36 +02:00
perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter
IBS hardware with the OpCntExt feature gets a 7-bit wider internal
counter. Both the maximum and current count bitfields in the
IBS_OP_CTL register are extended to support reading and writing it.
No changes are necessary to the driver for handling the extra
contiguous current count bits (IbsOpCurCnt), as the driver already
passes through 32 bits of that field. However, the driver has to do
some extra bit manipulation when converting from a period to the
non-contiguous (although conveniently aligned) extra bits in the
IbsOpMaxCnt bitfield.
This decreases IBS Op interrupt overhead when the period is over
1,048,560 (0x0), which would previously activate the driver's
software counter. That threshold is now 134,217,712 (0x7f0).
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200908214740.18097-7-kim.phill...@amd.com
---
arch/x86/events/amd/ibs.c | 42 ++
arch/x86/include/asm/perf_event.h | 1 +-
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index cfbd020..ea323dc 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -339,10 +339,13 @@ static u64 get_ibs_op_count(u64 config)
* and the lower 7 bits of CurCnt are randomized.
* Otherwise CurCnt has the full 27-bit current counter value.
*/
- if (config & IBS_OP_VAL)
+ if (config & IBS_OP_VAL) {
count = (config & IBS_OP_MAX_CNT) << 4;
- else if (ibs_caps & IBS_CAPS_RDWROPCNT)
+ if (ibs_caps & IBS_CAPS_OPCNTEXT)
+ count += config & IBS_OP_MAX_CNT_EXT_MASK;
+ } else if (ibs_caps & IBS_CAPS_RDWROPCNT) {
count = (config & IBS_OP_CUR_CNT) >> 32;
+ }
return count;
}
@@ -398,7 +401,7 @@ static void perf_ibs_start(struct perf_event *event, int
flags)
struct hw_perf_event *hwc = >hw;
struct perf_ibs *perf_ibs = container_of(event->pmu, struct perf_ibs,
pmu);
struct cpu_perf_ibs *pcpu = this_cpu_ptr(perf_ibs->pcpu);
- u64 period;
+ u64 period, config = 0;
if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
return;
@@ -407,13 +410,19 @@ static void perf_ibs_start(struct perf_event *event, int
flags)
hwc->state = 0;
perf_ibs_set_period(perf_ibs, hwc, );
+ if (perf_ibs == _ibs_op && (ibs_caps & IBS_CAPS_OPCNTEXT)) {
+ config |= period & IBS_OP_MAX_CNT_EXT_MASK;
+ period &= ~IBS_OP_MAX_CNT_EXT_MASK;
+ }
+ config |= period >> 4;
+
/*
* Set STARTED before enabling the hardware, such that a subsequent NMI
* must observe it.
*/
set_bit(IBS_STARTED,pcpu->state);
clear_bit(IBS_STOPPING, pcpu->state);
- perf_ibs_enable_event(perf_ibs, hwc, period >> 4);
+ perf_ibs_enable_event(perf_ibs, hwc, config);
perf_event_update_userpage(event);
}
@@ -581,7 +590,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
struct perf_ibs_data ibs_data;
int offset, size, check_rip, offset_max, throttle = 0;
unsigned int msr;
- u64 *buf, *config, period;
+ u64 *buf, *config, period, new_config = 0;
if (!test_bit(IBS_STARTED, pcpu->state)) {
fail:
@@ -676,13 +685,17 @@ out:
if (throttle) {
perf_ibs_stop(event, 0);
} else {
- period >>= 4;
-
- if ((ibs_caps & IBS_CAPS_RDWROPCNT) &&
- (*config & IBS_OP_CNT_CTL))
- period |= *config & IBS_OP_CUR_CNT_RAND;
+ if (perf_ibs == _ibs_op) {
+ if (ibs_caps & IBS_CAPS_OPCNTEXT) {
+ new_config = period & IBS_OP_MAX_CNT_EXT_MASK;
+ period &= ~IBS_OP_MAX_CNT_EXT_MASK;
+ }
+ if ((ibs_caps & IBS_CAPS_RDWROPCNT) && (*config &
IBS_OP_CNT_CTL))
+ new_config |= *config & IBS_OP_CUR_CNT_RAND;
+ }
+ new_config |= period >> 4;
- perf_ibs_enable_event(perf_ibs, hwc, period);
+ perf_ibs_enable_event(perf_ibs, hwc, new_config);
}
perf_event_up
[tip: perf/core] perf/x86/rapl: Add AMD Fam19h RAPL support
The following commit has been merged into the perf/core branch of tip:
Commit-ID: a77259bdcb62a2c345914df659a1fbc421269a8b
Gitweb:
https://git.kernel.org/tip/a77259bdcb62a2c345914df659a1fbc421269a8b
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:40 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:36 +02:00
perf/x86/rapl: Add AMD Fam19h RAPL support
Family 19h RAPL support did not change from Family 17h; extend
the existing Fam17h support to work on Family 19h too.
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20200908214740.18097-8-kim.phill...@amd.com
---
arch/x86/events/rapl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index 67b411f..7c0120e 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -815,6 +815,7 @@ static const struct x86_cpu_id rapl_model_match[]
__initconst = {
X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,_spr),
X86_MATCH_VENDOR_FAM(AMD, 0x17, _amd_fam17h),
X86_MATCH_VENDOR_FAM(HYGON, 0x18, _amd_fam17h),
+ X86_MATCH_VENDOR_FAM(AMD, 0x19, _amd_fam17h),
{},
};
MODULE_DEVICE_TABLE(x86cpu, rapl_model_match);
[tip: perf/core] perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count()
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 680d69635005ba0e58fe3f4c52fc162b8fc743b0
Gitweb:
https://git.kernel.org/tip/680d69635005ba0e58fe3f4c52fc162b8fc743b0
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:37 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:35 +02:00
perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count()
get_ibs_op_count() adds hardware's current count (IbsOpCurCnt) bits
to its count regardless of hardware's valid status.
According to the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54,
if the counter rolls over, valid status is set, and the lower 7 bits
of IbsOpCurCnt are randomized by hardware.
Don't include those bits in the driver's event count.
Fixes: 8b1e13638d46 ("perf/x86-ibs: Fix usage of IBS op current count")
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc: sta...@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
---
arch/x86/events/amd/ibs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 26c3635..863174a 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -334,11 +334,15 @@ static u64 get_ibs_op_count(u64 config)
{
u64 count = 0;
+ /*
+* If the internal 27-bit counter rolled over, the count is MaxCnt
+* and the lower 7 bits of CurCnt are randomized.
+* Otherwise CurCnt has the full 27-bit current counter value.
+*/
if (config & IBS_OP_VAL)
- count += (config & IBS_OP_MAX_CNT) << 4; /* cnt rolled over */
-
- if (ibs_caps & IBS_CAPS_RDWROPCNT)
- count += (config & IBS_OP_CUR_CNT) >> 32;
+ count = (config & IBS_OP_MAX_CNT) << 4;
+ else if (ibs_caps & IBS_CAPS_RDWROPCNT)
+ count = (config & IBS_OP_CUR_CNT) >> 32;
return count;
}
[tip: perf/core] arch/x86/amd/ibs: Fix re-arming IBS Fetch
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 221bfce5ebbdf72ff08b3bf2510ae81058ee568b
Gitweb:
https://git.kernel.org/tip/221bfce5ebbdf72ff08b3bf2510ae81058ee568b
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:36 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:36 +02:00
arch/x86/amd/ibs: Fix re-arming IBS Fetch
Stephane Eranian found a bug in that IBS' current Fetch counter was not
being reset when the driver would write the new value to clear it along
with the enable bit set, and found that adding an MSR write that would
first disable IBS Fetch would make IBS Fetch reset its current count.
Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12,
2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when
IbsFetchEn is changed from 0 to 1."
Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch,
so the driver properly resets the internal counter to 0 and IBS
Fetch starts counting again.
A family 15h machine tested does not have this problem, and the extra
wrmsr is also not needed on Family 19h, so only do the extra wrmsr on
families 16h through 18h.
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
[peterz: optimized]
Signed-off-by: Peter Zijlstra (Intel)
Cc: sta...@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
---
arch/x86/events/amd/ibs.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index ea323dc..40669ea 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -89,6 +89,7 @@ struct perf_ibs {
u64 max_period;
unsigned long offset_mask[1];
int offset_max;
+ unsigned intfetch_count_reset_broken : 1;
struct cpu_perf_ibs __percpu*pcpu;
struct attribute**format_attrs;
@@ -370,7 +371,12 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct
perf_event *event,
static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
struct hw_perf_event *hwc, u64 config)
{
- wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
+ u64 tmp = hwc->config | config;
+
+ if (perf_ibs->fetch_count_reset_broken)
+ wrmsrl(hwc->config_base, tmp & ~perf_ibs->enable_mask);
+
+ wrmsrl(hwc->config_base, tmp | perf_ibs->enable_mask);
}
/*
@@ -756,6 +762,13 @@ static __init void perf_event_ibs_init(void)
{
struct attribute **attr = ibs_op_format_attrs;
+ /*
+* Some chips fail to reset the fetch count when it is written; instead
+* they need a 0-1 transition of IbsFetchEn.
+*/
+ if (boot_cpu_data.x86 >= 0x16 && boot_cpu_data.x86 <= 0x18)
+ perf_ibs_fetch.fetch_count_reset_broken = 1;
+
perf_ibs_pmu_init(_ibs_fetch, "ibs_fetch");
if (ibs_caps & IBS_CAPS_OPCNT) {
[tip: perf/core] perf/x86/amd: Fix sampling Large Increment per Cycle events
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 26e52558ead4b39c0e0fe7bf08f82f5a9777a412
Gitweb:
https://git.kernel.org/tip/26e52558ead4b39c0e0fe7bf08f82f5a9777a412
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:35 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:35 +02:00
perf/x86/amd: Fix sampling Large Increment per Cycle events
Commit 5738891229a2 ("perf/x86/amd: Add support for Large Increment
per Cycle Events") mistakenly zeroes the upper 16 bits of the count
in set_period(). That's fine for counting with perf stat, but not
sampling with perf record when only Large Increment events are being
sampled. To enable sampling, we sign extend the upper 16 bits of the
merged counter pair as described in the Family 17h PPRs:
"Software wanting to preload a value to a merged counter pair writes the
high-order 16-bit value to the low-order 16 bits of the odd counter and
then writes the low-order 48-bit value to the even counter. Reading the
even counter of the merged counter pair returns the full 64-bit value."
Fixes: 5738891229a2 ("perf/x86/amd: Add support for Large Increment per Cycle
Events")
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc: sta...@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
---
arch/x86/events/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 0f3d015..cb5cfef 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1326,11 +1326,11 @@ int x86_perf_event_set_period(struct perf_event *event)
wrmsrl(hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);
/*
-* Clear the Merge event counter's upper 16 bits since
+* Sign extend the Merge event counter's upper 16 bits since
* we currently declare a 48-bit counter width
*/
if (is_counter_pair(hwc))
- wrmsrl(x86_pmu_event_addr(idx + 1), 0);
+ wrmsrl(x86_pmu_event_addr(idx + 1), 0x);
/*
* Due to erratum on certan cpu we need
[tip: perf/core] perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour
The following commit has been merged into the perf/core branch of tip:
Commit-ID: c8fe99d0701fec9fb849ec880a86bc5592530496
Gitweb:
https://git.kernel.org/tip/c8fe99d0701fec9fb849ec880a86bc5592530496
Author:Kim Phillips
AuthorDate:Tue, 08 Sep 2020 16:47:34 -05:00
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:34 +02:00
perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour
Commit 2f217d58a8a0 ("perf/x86/amd/uncore: Set the thread mask for
F17h L3 PMCs") inadvertently changed the uncore driver's behaviour
wrt perf tool invocations with or without a CPU list, specified with
-C / --cpu=.
Change the behaviour of the driver to assume the former all-cpu (-a)
case, which is the more commonly desired default. This fixes
'-a -A' invocations without explicit cpu lists (-C) to not count
L3 events only on behalf of the first thread of the first core
in the L3 domain.
BEFORE:
Activity performed by the first thread of the last core (CPU#43) in
CPU#40's L3 domain is not reported by CPU#40:
sudo perf stat -a -A -e l3_request_g1.caching_l3_cache_accesses taskset -c 43
perf bench mem memcpy -s 32mb -l 100 -f default
...
CPU36 21,835 l3_request_g1.caching_l3_cache_accesses
CPU40 87,066 l3_request_g1.caching_l3_cache_accesses
CPU44 17,360 l3_request_g1.caching_l3_cache_accesses
...
AFTER:
The L3 domain activity is now reported by CPU#40:
sudo perf stat -a -A -e l3_request_g1.caching_l3_cache_accesses taskset -c 43
perf bench mem memcpy -s 32mb -l 100 -f default
...
CPU36354,891 l3_request_g1.caching_l3_cache_accesses
CPU40 1,780,870 l3_request_g1.caching_l3_cache_accesses
CPU44315,062 l3_request_g1.caching_l3_cache_accesses
...
Fixes: 2f217d58a8a0 ("perf/x86/amd/uncore: Set the thread mask for F17h L3
PMCs")
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20200908214740.18097-2-kim.phill...@amd.com
---
arch/x86/events/amd/uncore.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 76400c0..e7e61c8 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -181,28 +181,16 @@ static void amd_uncore_del(struct perf_event *event, int
flags)
}
/*
- * Convert logical CPU number to L3 PMC Config ThreadMask format
+ * Return a full thread and slice mask until per-CPU is
+ * properly supported.
*/
-static u64 l3_thread_slice_mask(int cpu)
+static u64 l3_thread_slice_mask(void)
{
- u64 thread_mask, core = topology_core_id(cpu);
- unsigned int shift, thread = 0;
+ if (boot_cpu_data.x86 <= 0x18)
+ return AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK;
- if (topology_smt_supported() && !topology_is_primary_thread(cpu))
- thread = 1;
-
- if (boot_cpu_data.x86 <= 0x18) {
- shift = AMD64_L3_THREAD_SHIFT + 2 * (core % 4) + thread;
- thread_mask = BIT_ULL(shift);
-
- return AMD64_L3_SLICE_MASK | thread_mask;
- }
-
- core = (core << AMD64_L3_COREID_SHIFT) & AMD64_L3_COREID_MASK;
- shift = AMD64_L3_THREAD_SHIFT + thread;
- thread_mask = BIT_ULL(shift);
-
- return AMD64_L3_EN_ALL_SLICES | core | thread_mask;
+ return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
+ AMD64_L3_F19H_THREAD_MASK;
}
static int amd_uncore_event_init(struct perf_event *event)
@@ -232,7 +220,7 @@ static int amd_uncore_event_init(struct perf_event *event)
* For other events, the two fields do not affect the count.
*/
if (l3_mask && is_llc_event(event))
- hwc->config |= l3_thread_slice_mask(event->cpu);
+ hwc->config |= l3_thread_slice_mask();
uncore = event_to_amd_uncore(event);
if (!uncore)
Re: [PATCH v2 3/7] arch/x86/amd/ibs: Fix re-arming IBS Fetch
On 9/10/20 3:50 AM, pet...@infradead.org wrote:
> On Thu, Sep 10, 2020 at 10:32:23AM +0200, pet...@infradead.org wrote:
>>> @@ -363,7 +363,14 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs,
>>> struct perf_event *event,
>>> static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
>>> struct hw_perf_event *hwc, u64 config)
>>> {
>>> - wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
>>> + u64 _config = (hwc->config | config) & ~perf_ibs->enable_mask;
>>> +
>>> + /* On Fam17h, the periodic fetch counter is set when IbsFetchEn is
>>> changed from 0 to 1 */
>>> + if (perf_ibs == _ibs_fetch && boot_cpu_data.x86 >= 0x16 &&
>>> boot_cpu_data.x86 <= 0x18)
>>> + wrmsrl(hwc->config_base, _config);
>
>> A better option would be to use hwc->flags, you're loading from that
>> line already, so it's guaranteed hot and then you only have a single
>> branch. Or stick it in perf_ibs near enable_mask, same difference.
>
> I fixed it for you.
> @@ -370,7 +371,13 @@ perf_ibs_event_update(struct perf_ibs *p
> static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
>struct hw_perf_event *hwc, u64 config)
> {
> - wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
> + u64 _config = (hwc->config | config) & ~perf_ibs->enable_mask;
> +
> + if (perf_ibs->fetch_count_reset_broken)
Nice, we don't even need the perf_ibs == _ibs_fetch check
here because fetch_count_reset_broken is guaranteed to be 0 in
perf_ibs_op.
Thanks!
Kim
[PATCH v2 7/7] perf/x86/rapl: Add AMD Fam19h RAPL support
Family 19h RAPL support did not change from Family 17h; extend
the existing Fam17h support to work on Family 19h too.
Signed-off-by: Kim Phillips
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
---
v2: no changes.
arch/x86/events/rapl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index 67b411f7e8c4..7c0120e2e957 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -815,6 +815,7 @@ static const struct x86_cpu_id rapl_model_match[]
__initconst = {
X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,_spr),
X86_MATCH_VENDOR_FAM(AMD, 0x17, _amd_fam17h),
X86_MATCH_VENDOR_FAM(HYGON, 0x18, _amd_fam17h),
+ X86_MATCH_VENDOR_FAM(AMD, 0x19, _amd_fam17h),
{},
};
MODULE_DEVICE_TABLE(x86cpu, rapl_model_match);
--
2.27.0
[PATCH v2 6/7] perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter
IBS hardware with the OpCntExt feature gets a 7-bit wider internal
counter. Both the maximum and current count bitfields in the
IBS_OP_CTL register are extended to support reading and writing it.
No changes are necessary to the driver for handling the extra
contiguous current count bits (IbsOpCurCnt), as the driver already
passes through 32 bits of that field. However, the driver has to do
some extra bit manipulation when converting from a period to the
non-contiguous (although conveniently aligned) extra bits in the
IbsOpMaxCnt bitfield.
This decreases IBS Op interrupt overhead when the period is over
1,048,560 (0x0), which would previously activate the driver's
software counter. That threshold is now 134,217,712 (0x7f0).
Signed-off-by: Kim Phillips
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
---
v2: no changes.
arch/x86/events/amd/ibs.c | 42 +++
arch/x86/include/asm/perf_event.h | 1 +
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index ace28be4cbda..2766a7763d38 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -339,10 +339,13 @@ static u64 get_ibs_op_count(u64 config)
* and the lower 7 bits of CurCnt are randomized.
* Otherwise CurCnt has the full 27-bit current counter value.
*/
- if (config & IBS_OP_VAL)
+ if (config & IBS_OP_VAL) {
count = (config & IBS_OP_MAX_CNT) << 4;
- else if (ibs_caps & IBS_CAPS_RDWROPCNT)
+ if (ibs_caps & IBS_CAPS_OPCNTEXT)
+ count += config & IBS_OP_MAX_CNT_EXT_MASK;
+ } else if (ibs_caps & IBS_CAPS_RDWROPCNT) {
count = (config & IBS_OP_CUR_CNT) >> 32;
+ }
return count;
}
@@ -405,7 +408,7 @@ static void perf_ibs_start(struct perf_event *event, int
flags)
struct hw_perf_event *hwc = >hw;
struct perf_ibs *perf_ibs = container_of(event->pmu, struct perf_ibs,
pmu);
struct cpu_perf_ibs *pcpu = this_cpu_ptr(perf_ibs->pcpu);
- u64 period;
+ u64 period, config = 0;
if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
return;
@@ -414,13 +417,19 @@ static void perf_ibs_start(struct perf_event *event, int
flags)
hwc->state = 0;
perf_ibs_set_period(perf_ibs, hwc, );
+ if (perf_ibs == _ibs_op && (ibs_caps & IBS_CAPS_OPCNTEXT)) {
+ config |= period & IBS_OP_MAX_CNT_EXT_MASK;
+ period &= ~IBS_OP_MAX_CNT_EXT_MASK;
+ }
+ config |= period >> 4;
+
/*
* Set STARTED before enabling the hardware, such that a subsequent NMI
* must observe it.
*/
set_bit(IBS_STARTED,pcpu->state);
clear_bit(IBS_STOPPING, pcpu->state);
- perf_ibs_enable_event(perf_ibs, hwc, period >> 4);
+ perf_ibs_enable_event(perf_ibs, hwc, config);
perf_event_update_userpage(event);
}
@@ -588,7 +597,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
struct perf_ibs_data ibs_data;
int offset, size, check_rip, offset_max, throttle = 0;
unsigned int msr;
- u64 *buf, *config, period;
+ u64 *buf, *config, period, new_config = 0;
if (!test_bit(IBS_STARTED, pcpu->state)) {
fail:
@@ -683,13 +692,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
if (throttle) {
perf_ibs_stop(event, 0);
} else {
- period >>= 4;
-
- if ((ibs_caps & IBS_CAPS_RDWROPCNT) &&
- (*config & IBS_OP_CNT_CTL))
- period |= *config & IBS_OP_CUR_CNT_RAND;
+ if (perf_ibs == _ibs_op) {
+ if (ibs_caps & IBS_CAPS_OPCNTEXT) {
+ new_config = period & IBS_OP_MAX_CNT_EXT_MASK;
+ period &= ~IBS_OP_MAX_CNT_EXT_MASK;
+ }
+ if ((ibs_caps & IBS_CAPS_RDWROPCNT) && (*config &
IBS_OP_CNT_CTL))
+ new_config |= *config & IBS_OP_CUR_CNT_RAND;
+ }
+ new_config |= period >> 4;
- perf_ibs_enable_event(perf_ibs, hwc, period);
+ perf_ibs_enable_event(perf_ibs, hwc, new_config);
}
perf_event_update_userpage(event);
@@ -756,6 +769,13 @@ static __init void perf_event_ibs_init(void)
perf_ibs_op.config_mask |= IBS_OP
[PATCH v2 5/7] perf/x86/amd/ibs: Fix raw sample data accumulation
Neither IbsBrTarget nor OPDATA4 are populated in IBS Fetch mode.
Don't accumulate them into raw sample user data in that case.
Also, in Fetch mode, add saving the IBS Fetch Control Extended MSR.
Technically, there is an ABI change here with respect to the IBS raw
sample data format, but I don't see any perf driver version information
being included in perf.data file headers, but, existing users can detect
whether the size of the sample record has reduced by 8 bytes to
determine whether the IBS driver has this fix.
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
Fixes: 904cb3677f3a ("perf/x86/amd/ibs: Update IBS MSRs and feature
definitions")
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
v2: no changes.
arch/x86/events/amd/ibs.c| 26 --
arch/x86/include/asm/msr-index.h | 1 +
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 68776cc291a6..ace28be4cbda 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -637,18 +637,24 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
perf_ibs->offset_max,
offset + 1);
} while (offset < offset_max);
+ /*
+* Read IbsBrTarget, IbsOpData4, and IbsExtdCtl separately
+* depending on their availability.
+* Can't add to offset_max as they are staggered
+*/
if (event->attr.sample_type & PERF_SAMPLE_RAW) {
- /*
-* Read IbsBrTarget and IbsOpData4 separately
-* depending on their availability.
-* Can't add to offset_max as they are staggered
-*/
- if (ibs_caps & IBS_CAPS_BRNTRGT) {
- rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++);
- size++;
+ if (perf_ibs == _ibs_op) {
+ if (ibs_caps & IBS_CAPS_BRNTRGT) {
+ rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++);
+ size++;
+ }
+ if (ibs_caps & IBS_CAPS_OPDATA4) {
+ rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++);
+ size++;
+ }
}
- if (ibs_caps & IBS_CAPS_OPDATA4) {
- rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++);
+ if (perf_ibs == _ibs_fetch && (ibs_caps &
IBS_CAPS_FETCHCTLEXTD)) {
+ rdmsrl(MSR_AMD64_ICIBSEXTDCTL, *buf++);
size++;
}
}
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 2859ee4f39a8..b08c8a2afc0e 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -464,6 +464,7 @@
#define MSR_AMD64_IBSOP_REG_MASK ((1UL<
[PATCH v2 4/7] perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count()
get_ibs_op_count() adds hardware's current count (IbsOpCurCnt) bits
to its count regardless of hardware's valid status.
According to the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54,
if the counter rolls over, valid status is set, and the lower 7 bits
of IbsOpCurCnt are randomized by hardware.
Don't include those bits in the driver's event count.
Signed-off-by: Kim Phillips
Fixes: 8b1e13638d46 ("perf/x86-ibs: Fix usage of IBS op current count")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
v2: no changes.
arch/x86/events/amd/ibs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 3eb9a55e998c..68776cc291a6 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -334,11 +334,15 @@ static u64 get_ibs_op_count(u64 config)
{
u64 count = 0;
+ /*
+* If the internal 27-bit counter rolled over, the count is MaxCnt
+* and the lower 7 bits of CurCnt are randomized.
+* Otherwise CurCnt has the full 27-bit current counter value.
+*/
if (config & IBS_OP_VAL)
- count += (config & IBS_OP_MAX_CNT) << 4; /* cnt rolled over */
-
- if (ibs_caps & IBS_CAPS_RDWROPCNT)
- count += (config & IBS_OP_CUR_CNT) >> 32;
+ count = (config & IBS_OP_MAX_CNT) << 4;
+ else if (ibs_caps & IBS_CAPS_RDWROPCNT)
+ count = (config & IBS_OP_CUR_CNT) >> 32;
return count;
}
--
2.27.0
[PATCH v2 3/7] arch/x86/amd/ibs: Fix re-arming IBS Fetch
Stephane Eranian found a bug in that IBS' current Fetch counter was not
being reset when the driver would write the new value to clear it along
with the enable bit set, and found that adding an MSR write that would
first disable IBS Fetch would make IBS Fetch reset its current count.
Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12,
2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when
IbsFetchEn is changed from 0 to 1."
Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch,
so the driver properly resets the internal counter to 0 and IBS
Fetch starts counting again.
A family 15h machine tested does not have this problem, and the extra
wrmsr is also not needed on Family 19h, so only do the extra wrmsr on
families 16h through 18h.
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
v2: constrained the extra wrmsr to Families 16h through 18h, inclusive.
arch/x86/events/amd/ibs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 26c36357c4c9..3eb9a55e998c 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -363,7 +363,14 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct
perf_event *event,
static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
struct hw_perf_event *hwc, u64 config)
{
- wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
+ u64 _config = (hwc->config | config) & ~perf_ibs->enable_mask;
+
+ /* On Fam17h, the periodic fetch counter is set when IbsFetchEn is
changed from 0 to 1 */
+ if (perf_ibs == _ibs_fetch && boot_cpu_data.x86 >= 0x16 &&
boot_cpu_data.x86 <= 0x18)
+ wrmsrl(hwc->config_base, _config);
+
+ _config |= perf_ibs->enable_mask;
+ wrmsrl(hwc->config_base, _config);
}
/*
--
2.27.0
[PATCH v2 2/7] perf/x86/amd: Fix sampling Large Increment per Cycle events
Commit 5738891229a2 ("perf/x86/amd: Add support for Large Increment
per Cycle Events") mistakenly zeroes the upper 16 bits of the count
in set_period(). That's fine for counting with perf stat, but not
sampling with perf record when only Large Increment events are being
sampled. To enable sampling, we sign extend the upper 16 bits of the
merged counter pair as described in the Family 17h PPRs:
"Software wanting to preload a value to a merged counter pair writes the
high-order 16-bit value to the low-order 16 bits of the odd counter and
then writes the low-order 48-bit value to the even counter. Reading the
even counter of the merged counter pair returns the full 64-bit value."
Fixes: 5738891229a2 ("perf/x86/amd: Add support for Large Increment per Cycle
Events")
Signed-off-by: Kim Phillips
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
v2: no changes.
arch/x86/events/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 1cbf57dc2ac8..2fdc211e3e56 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1284,11 +1284,11 @@ int x86_perf_event_set_period(struct perf_event *event)
wrmsrl(hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);
/*
-* Clear the Merge event counter's upper 16 bits since
+* Sign extend the Merge event counter's upper 16 bits since
* we currently declare a 48-bit counter width
*/
if (is_counter_pair(hwc))
- wrmsrl(x86_pmu_event_addr(idx + 1), 0);
+ wrmsrl(x86_pmu_event_addr(idx + 1), 0x);
/*
* Due to erratum on certan cpu we need
--
2.27.0
[PATCH v2 1/7] perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour
Commit 2f217d58a8a0 ("perf/x86/amd/uncore: Set the thread mask for
F17h L3 PMCs") inadvertently changed the uncore driver's behaviour
wrt perf tool invocations with or without a CPU list, specified with
-C / --cpu=.
Change the behaviour of the driver to assume the former all-cpu (-a)
case, which is the more commonly desired default. This fixes
'-a -A' invocations without explicit cpu lists (-C) to not count
L3 events only on behalf of the first thread of the first core
in the L3 domain.
BEFORE:
Activity performed by the first thread of the last core (CPU#43) in
CPU#40's L3 domain is not reported by CPU#40:
sudo perf stat -a -A -e l3_request_g1.caching_l3_cache_accesses taskset -c 43
perf bench mem memcpy -s 32mb -l 100 -f default
...
CPU36 21,835 l3_request_g1.caching_l3_cache_accesses
CPU40 87,066 l3_request_g1.caching_l3_cache_accesses
CPU44 17,360 l3_request_g1.caching_l3_cache_accesses
...
AFTER:
The L3 domain activity is now reported by CPU#40:
sudo perf stat -a -A -e l3_request_g1.caching_l3_cache_accesses taskset -c 43
perf bench mem memcpy -s 32mb -l 100 -f default
...
CPU36354,891 l3_request_g1.caching_l3_cache_accesses
CPU40 1,780,870 l3_request_g1.caching_l3_cache_accesses
CPU44315,062 l3_request_g1.caching_l3_cache_accesses
...
Signed-off-by: Kim Phillips
Fixes: 2f217d58a8a0 ("perf/x86/amd/uncore: Set the thread mask for F17h L3
PMCs")
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
v2: no changes.
Original submission:
https://lore.kernel.org/lkml/20200323233159.19601-1-kim.phill...@amd.com/
arch/x86/events/amd/uncore.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 76400c052b0e..e7e61c8b56bd 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -181,28 +181,16 @@ static void amd_uncore_del(struct perf_event *event, int
flags)
}
/*
- * Convert logical CPU number to L3 PMC Config ThreadMask format
+ * Return a full thread and slice mask until per-CPU is
+ * properly supported.
*/
-static u64 l3_thread_slice_mask(int cpu)
+static u64 l3_thread_slice_mask(void)
{
- u64 thread_mask, core = topology_core_id(cpu);
- unsigned int shift, thread = 0;
+ if (boot_cpu_data.x86 <= 0x18)
+ return AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK;
- if (topology_smt_supported() && !topology_is_primary_thread(cpu))
- thread = 1;
-
- if (boot_cpu_data.x86 <= 0x18) {
- shift = AMD64_L3_THREAD_SHIFT + 2 * (core % 4) + thread;
- thread_mask = BIT_ULL(shift);
-
- return AMD64_L3_SLICE_MASK | thread_mask;
- }
-
- core = (core << AMD64_L3_COREID_SHIFT) & AMD64_L3_COREID_MASK;
- shift = AMD64_L3_THREAD_SHIFT + thread;
- thread_mask = BIT_ULL(shift);
-
- return AMD64_L3_EN_ALL_SLICES | core | thread_mask;
+ return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
+ AMD64_L3_F19H_THREAD_MASK;
}
static int amd_uncore_event_init(struct perf_event *event)
@@ -232,7 +220,7 @@ static int amd_uncore_event_init(struct perf_event *event)
* For other events, the two fields do not affect the count.
*/
if (l3_mask && is_llc_event(event))
- hwc->config |= l3_thread_slice_mask(event->cpu);
+ hwc->config |= l3_thread_slice_mask();
uncore = event_to_amd_uncore(event);
if (!uncore)
--
2.27.0
[PATCH v2 0/7] perf/x86/amd: Miscellaneous updates
Hi, Please merge: Patch 1/7 restores 'perf stat -a' behaviour to program the uncore PMU to count all CPU threads. Patch 2/7 fixes setting the proper count when sampling Large Increment per Cycle events / 'paired' events. The next 4 patches fix IBS Fetch sampling on F17h and some other IBS fine tuning, the last one greatly reducing the number of interrupts when large sample periods are specified. Finally, patch 7/7 extends Family 17h RAPL support to also work on compatible F19h machines. Thanks, Kim v2: Added this cover letter. The only patch that changed in this new submission is the fix for IBS Fetch sampling, which got a new family check after testing on some other family machines. Link to 1st patch in original submission of this series: https://lore.kernel.org/patchwork/patch/1289806/ Cc: Stephane Eranian Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: "H. Peter Anvin" Cc: Jiri Olsa Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: LKML Cc: x86 Kim Phillips (7): perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour perf/x86/amd: Fix sampling Large Increment per Cycle events arch/x86/amd/ibs: Fix re-arming IBS Fetch perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count() perf/x86/amd/ibs: Fix raw sample data accumulation perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter perf/x86/rapl: Add AMD Fam19h RAPL support arch/x86/events/amd/ibs.c | 87 ++- arch/x86/events/amd/uncore.c | 28 +++--- arch/x86/events/core.c| 4 +- arch/x86/events/rapl.c| 1 + arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/perf_event.h | 1 + 6 files changed, 75 insertions(+), 47 deletions(-) -- 2.27.0
Re: [PATCH 3/4] perf vendor events amd: Add recommended events
On 9/3/20 1:19 AM, Ian Rogers wrote: > On Tue, Sep 1, 2020 at 3:10 PM Kim Phillips wrote: >> The nps1_die_to_dram event may need perf stat's --metric-no-group >> switch if the number of available data fabric counters is less >> than the number it uses (8). > > These are really excellent additions! Does: > "MetricConstraint": "NO_NMI_WATCHDOG" > solve the grouping issue? Perhaps the MetricConstraint needs to be > named more generically to cover this case as it seems sub-optimal to > require the use of --metric-no-group. That metric uses data fabric (DFPMC/amd_df) events, not Core PMC events, which the watchdog uses, so NO_NMI_WATCHDOG wouldn't have an effect. The event is defined as an approximation anyway. I'll have to get back to you on the other items. Thanks for your review! Kim
[PATCH 4/4] perf vendor events amd: Enable Family 19h users by matching Zen2 events
This enables zen3 users by reusing mostly-compatible zen2 events until the official public list of zen3 events is published in a future PPR. Signed-off-by: Kim Phillips Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Mark Rutland Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Vijay Thakkar Cc: Andi Kleen Cc: John Garry Cc: Kan Liang Cc: Yunfeng Ye Cc: Jin Yao Cc: "Martin Liška" Cc: Borislav Petkov Cc: Jon Grimm Cc: Martin Jambor Cc: Michael Petlan Cc: William Cohen Cc: Stephane Eranian Cc: Ian Rogers Cc: linux-perf-us...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- tools/perf/pmu-events/arch/x86/mapfile.csv | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv b/tools/perf/pmu-events/arch/x86/mapfile.csv index 25b06cf98747..2f2a209e87e1 100644 --- a/tools/perf/pmu-events/arch/x86/mapfile.csv +++ b/tools/perf/pmu-events/arch/x86/mapfile.csv @@ -38,3 +38,4 @@ GenuineIntel-6-7E,v1,icelake,core GenuineIntel-6-86,v1,tremontx,core AuthenticAMD-23-([12][0-9A-F]|[0-9A-F]),v2,amdzen1,core AuthenticAMD-23-[[:xdigit:]]+,v1,amdzen2,core +AuthenticAMD-25-[[:xdigit:]]+,v1,amdzen2,core -- 2.27.0
[PATCH 3/4] perf vendor events amd: Add recommended events
Add support for events listed in Section 2.1.15.2 "Performance
Measurement" of "PPR for AMD Family 17h Model 31h B0 - 55803
Rev 0.54 - Sep 12, 2019".
perf now supports these new events (-e):
all_dc_accesses
all_tlbs_flushed
l1_dtlb_misses
l2_cache_accesses_from_dc_misses
l2_cache_accesses_from_ic_misses
l2_cache_hits_from_dc_misses
l2_cache_hits_from_ic_misses
l2_cache_misses_from_dc_misses
l2_cache_misses_from_ic_miss
l2_dtlb_misses
l2_itlb_misses
sse_avx_stalls
uops_dispatched
uops_retired
l3_accesses
l3_misses
and these metrics (-M):
branch_misprediction_ratio
all_l2_cache_accesses
all_l2_cache_hits
all_l2_cache_misses
ic_fetch_miss_ratio
l2_cache_accesses_from_l2_hwpf
l2_cache_hits_from_l2_hwpf
l2_cache_misses_from_l2_hwpf
l3_read_miss_latency
l1_itlb_misses
all_remote_links_outbound
nps1_die_to_dram
The nps1_die_to_dram event may need perf stat's --metric-no-group
switch if the number of available data fabric counters is less
than the number it uses (8).
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Signed-off-by: Kim Phillips
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Vijay Thakkar
Cc: Andi Kleen
Cc: John Garry
Cc: Kan Liang
Cc: Yunfeng Ye
Cc: Jin Yao
Cc: "Martin Liška"
Cc: Borislav Petkov
Cc: Jon Grimm
Cc: Martin Jambor
Cc: Michael Petlan
Cc: William Cohen
Cc: Stephane Eranian
Cc: Ian Rogers
Cc: linux-perf-us...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
.../pmu-events/arch/x86/amdzen1/cache.json| 23 +++
.../arch/x86/amdzen1/data-fabric.json | 98 ++
.../arch/x86/amdzen1/recommended.json | 178 ++
.../pmu-events/arch/x86/amdzen2/cache.json| 23 +++
.../arch/x86/amdzen2/data-fabric.json | 98 ++
.../arch/x86/amdzen2/recommended.json | 178 ++
tools/perf/pmu-events/jevents.c | 1 +
7 files changed, 599 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
create mode 100644 tools/perf/pmu-events/arch/x86/amdzen1/recommended.json
create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/data-fabric.json
create mode 100644 tools/perf/pmu-events/arch/x86/amdzen2/recommended.json
diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
index 695ed3ffa3a6..4ea7ec4f496e 100644
--- a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
+++ b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
@@ -117,6 +117,11 @@
"BriefDescription": "Miscellaneous events covered in more detail by
l2_request_g2 (PMCx061).",
"UMask": "0x1"
},
+ {
+"EventName": "l2_request_g1.all_no_prefetch",
+"EventCode": "0x60",
+"UMask": "0xf9"
+ },
{
"EventName": "l2_request_g2.group1",
"EventCode": "0x61",
@@ -243,6 +248,24 @@
"BriefDescription": "Core to L2 cacheable request access status (not
including L2 Prefetch). Instruction cache request miss in L2.",
"UMask": "0x1"
},
+ {
+"EventName": "l2_cache_req_stat.ic_access_in_l2",
+"EventCode": "0x64",
+"BriefDescription": "Core to L2 cacheable request access status (not
including L2 Prefetch). Instruction cache requests in L2.",
+"UMask": "0x7"
+ },
+ {
+"EventName": "l2_cache_req_stat.ic_dc_miss_in_l2",
+"EventCode": "0x64",
+"BriefDescription": "Core to L2 cacheable request access status (not
including L2 Prefetch). Instruction cache request miss in L2 and Data cache
request miss in L2 (all types).",
+"UMask": "0x9"
+ },
+ {
+"EventName": "l2_cache_req_stat.ic_dc_hit_in_l2",
+"EventCode": "0x64",
+"BriefDescription": "Core to L2 cacheable request access status (not
including L2 Prefetch). Instruction cache request hit in L2 and Data cache
request hit in L2 (all types).",
+"UMask": "0xf6"
+ },
{
"EventName": "l2_fill_pending.l2_fill_busy",
"EventCode": "0x6d",
diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
b/tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
new file mode 100644
index ..40271df40015
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/amdzen1/data-fabric.json
@@ -0,0 +1,98 @@
+[
+ {
+"EventName": "remote_outbound_data_controller_0",
+"PublicDescription": "Remote Link Controller O
[PATCH 1/4] perf vendor events amd: Add L2 Prefetch events for zen1
Later revisions of PPRs that post-date the original Family 17h events
submission patch add these events.
Specifically, they were not in this 2017 revision of the F17h PPR:
Processor Programming Reference (PPR) for AMD Family 17h Model 01h, Revision B1
Processors Rev 1.14 - April 15, 2017
But e.g., are included in this 2019 version of the PPR:
Processor Programming Reference (PPR) for AMD Family 17h Model 18h, Revision B1
Processors Rev. 3.14 - Sep 26, 2019
Signed-off-by: Kim Phillips
Fixes: 98c07a8f74f8 ("perf vendor events amd: perf PMU events for AMD Family
17h")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Vijay Thakkar
Cc: Andi Kleen
Cc: John Garry
Cc: Kan Liang
Cc: Yunfeng Ye
Cc: Jin Yao
Cc: "Martin Liška"
Cc: Borislav Petkov
Cc: Jon Grimm
Cc: Martin Jambor
Cc: Michael Petlan
Cc: William Cohen
Cc: Stephane Eranian
Cc: Ian Rogers
Cc: linux-perf-us...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
.../pmu-events/arch/x86/amdzen1/cache.json | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
index 404d4c569c01..695ed3ffa3a6 100644
--- a/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
+++ b/tools/perf/pmu-events/arch/x86/amdzen1/cache.json
@@ -249,6 +249,24 @@
"BriefDescription": "Cycles with fill pending from L2. Total cycles spent
with one or more fill requests in flight from L2.",
"UMask": "0x1"
},
+ {
+"EventName": "l2_pf_hit_l2",
+"EventCode": "0x70",
+"BriefDescription": "L2 prefetch hit in L2.",
+"UMask": "0xff"
+ },
+ {
+"EventName": "l2_pf_miss_l2_hit_l3",
+"EventCode": "0x71",
+"BriefDescription": "L2 prefetcher hits in L3. Counts all L2 prefetches
accepted by the L2 pipeline which miss the L2 cache and hit the L3.",
+"UMask": "0xff"
+ },
+ {
+"EventName": "l2_pf_miss_l2_l3",
+"EventCode": "0x72",
+"BriefDescription": "L2 prefetcher misses in L3. All L2 prefetches
accepted by the L2 pipeline which miss the L2 and the L3 caches.",
+"UMask": "0xff"
+ },
{
"EventName": "l3_request_g1.caching_l3_cache_accesses",
"EventCode": "0x01",
--
2.27.0
[PATCH 2/4] perf vendor events amd: Add ITLB Instruction Fetch Hits event for zen1
The ITLB Instruction Fetch Hits event isn't documented even in
later zen1 PPRs, but it seems to count correctly on zen1 hardware.
Add it to zen1 group so zen1 users can use the upcoming IC Fetch Miss
Ratio Metric.
The IF1G, 1IF2M, IF4K (Instruction fetches to a 1 GB, 2 MB, and 4K page)
unit masks are not added because unlike zen2 hardware, zen1 hardware
counts all its unit masks with a 0 unit mask according to the old
convention:
zen1$ perf stat -e cpu/event=0x94/,cpu/event=0x94,umask=0xff/ sleep 1
Performance counter stats for 'sleep 1':
211,318 cpu/event=0x94/u
211,318 cpu/event=0x94,umask=0xff/u
Rome/zen2:
zen2$ perf stat -e cpu/event=0x94/,cpu/event=0x94,umask=0xff/ sleep 1
Performance counter stats for 'sleep 1':
0 cpu/event=0x94/u
190,744 cpu/event=0x94,umask=0xff/u
Signed-off-by: Kim Phillips
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Vijay Thakkar
Cc: Andi Kleen
Cc: John Garry
Cc: Kan Liang
Cc: Yunfeng Ye
Cc: Jin Yao
Cc: "Martin Liška"
Cc: Borislav Petkov
Cc: Jon Grimm
Cc: Martin Jambor
Cc: Michael Petlan
Cc: William Cohen
Cc: Stephane Eranian
Cc: Ian Rogers
Cc: linux-perf-us...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
tools/perf/pmu-events/arch/x86/amdzen1/branch.json | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
b/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
index a9943eeb8d6b..4ceb67a0db21 100644
--- a/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
+++ b/tools/perf/pmu-events/arch/x86/amdzen1/branch.json
@@ -19,5 +19,10 @@
"EventName": "bp_de_redirect",
"EventCode": "0x91",
"BriefDescription": "Decoder Overrides Existing Branch Prediction
(speculative)."
+ },
+ {
+"EventName": "bp_l1_tlb_fetch_hit",
+"EventCode": "0x94",
+"BriefDescription": "The number of instruction fetches that hit in the L1
ITLB."
}
]
--
2.27.0
[PATCH] perf record/stat: Explicitly call out event modifiers in the documentation
Event modifiers are not mentioned in the perf record or perf stat
manpages. Add them to orient new users more effectively by pointing
them to the perf list manpage for details.
Signed-off-by: Kim Phillips
Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS")
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Mark Rutland
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Adrian Hunter
Cc: Stephane Eranian
Cc: Alexey Budankov
Cc: Tony Jones
Cc: Jin Yao
Cc: Ian Rogers
Cc: "Paul A. Clarke"
Cc: linux-perf-us...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
tools/perf/Documentation/perf-record.txt | 4
tools/perf/Documentation/perf-stat.txt | 4
2 files changed, 8 insertions(+)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 3f72d8e261f3..bd50cdff08a8 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -33,6 +33,10 @@ OPTIONS
- a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
hexadecimal event descriptor.
+- a symbolic or raw PMU event followed by an optional colon
+ and a list of event modifiers, e.g., cpu-cycles:p. See the
+ linkperf:perf-list[1] man page for details on event modifiers.
+
- a symbolically formed PMU event like 'pmu/param1=0x3,param2/' where
'param1', 'param2', etc are defined as formats for the PMU in
/sys/bus/event_source/devices//format/*.
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index c9bfefc051fb..a4b1d11fefc8 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -39,6 +39,10 @@ report::
- a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a
hexadecimal event descriptor.
+- a symbolic or raw PMU event followed by an optional colon
+ and a list of event modifiers, e.g., cpu-cycles:p. See the
+ linkperf:perf-list[1] man page for details on event modifiers.
+
- a symbolically formed event like 'pmu/param1=0x3,param2/' where
param1 and param2 are defined as formats for the PMU in
/sys/bus/event_source/devices//format/*
--
2.27.0
[PATCH] tools/power turbostat: Support AMD Family 19h
Family 19h processors have the same RAPL (Running average power limit)
hardware register interface as Family 17h processors.
Change the family checks to succeed for Family 17h and above to enable
core and package energy measurement on Family 19h machines.
Also update the TDP to the largest found at the bottom of the page at
amd.com->processors->servers->epyc->2nd-gen-epyc, i.e., the EPYC 7H12.
Signed-off-by: Kim Phillips
Cc: Len Brown
Cc: Len Brown
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
tools/power/x86/turbostat/turbostat.c | 34 +--
1 file changed, 11 insertions(+), 23 deletions(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index 33b370865d16..e38f8a0c688f 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -3881,13 +3881,8 @@ double get_tdp_intel(unsigned int model)
double get_tdp_amd(unsigned int family)
{
- switch (family) {
- case 0x17:
- case 0x18:
- default:
- /* This is the max stock TDP of HEDT/Server Fam17h chips */
- return 250.0;
- }
+ /* This is the max stock TDP of HEDT/Server Fam17h+ chips */
+ return 280.0;
}
/*
@@ -4069,27 +4064,20 @@ void rapl_probe_amd(unsigned int family, unsigned int
model)
if (max_extended_level >= 0x8007) {
__cpuid(0x8007, eax, ebx, ecx, edx);
- /* RAPL (Fam 17h) */
+ /* RAPL (Fam 17h+) */
has_rapl = edx & (1 << 14);
}
- if (!has_rapl)
+ if (!has_rapl || family < 0x17)
return;
- switch (family) {
- case 0x17: /* Zen, Zen+ */
- case 0x18: /* Hygon Dhyana */
- do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
- if (rapl_joules) {
- BIC_PRESENT(BIC_Pkg_J);
- BIC_PRESENT(BIC_Cor_J);
- } else {
- BIC_PRESENT(BIC_PkgWatt);
- BIC_PRESENT(BIC_CorWatt);
- }
- break;
- default:
- return;
+ do_rapl = RAPL_AMD_F17H | RAPL_PER_CORE_ENERGY;
+ if (rapl_joules) {
+ BIC_PRESENT(BIC_Pkg_J);
+ BIC_PRESENT(BIC_Cor_J);
+ } else {
+ BIC_PRESENT(BIC_PkgWatt);
+ BIC_PRESENT(BIC_CorWatt);
}
if (get_msr(base_cpu, MSR_RAPL_PWR_UNIT, ))
--
2.27.0
[PATCH] powercap: Add AMD Fam19h RAPL support
AMD Family 19h's RAPL MSRs are identical to Family 17h's. Extend
Family 17h's support to Family 19h.
Signed-off-by: Kim Phillips
Cc: "Rafael J. Wysocki"
Cc: Victor Ding
Cc: LKML
Cc: linux...@vger.kernel.org
Cc: x...@kernel.org
---
Depends on Victor Ding's "powercap: Enable RAPL for AMD Fam17h"
series, submitted here:
https://lore.kernel.org/lkml/20200729105206.2991064-1-victord...@google.com/
drivers/powercap/intel_rapl_common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/intel_rapl_common.c
b/drivers/powercap/intel_rapl_common.c
index 2e311f9c0d85..1bc0e67cd7a4 100644
--- a/drivers/powercap/intel_rapl_common.c
+++ b/drivers/powercap/intel_rapl_common.c
@@ -1052,6 +1052,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,
_defaults_hsw_server),
X86_MATCH_VENDOR_FAM(AMD, 0x17, _defaults_core),
+ X86_MATCH_VENDOR_FAM(AMD, 0x19, _defaults_core),
{}
};
MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
--
2.27.0
Re: [PATCH 3/3] powercap: Add AMD Fam17h RAPL support
On 7/29/20 5:52 AM, Victor Ding wrote: > This patch enables AMD Fam17h RAPL support for the power capping > framework. The support is as per AMD Fam17h Model31h (Zen2) and > model 00-ffh (Zen1) PPR. > > Tested by comparing the results of following two sysfs entries and the > values directly read from corresponding MSRs via /dev/cpu/[x]/msr: > /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj > /sys/class/powercap/intel-rapl/intel-rapl:0/intel-rapl:0:0/energy_uj > > Signed-off-by: Victor Ding > --- For the series: Acked-by: Kim Phillips Thanks, Kim
[PATCH 7/7] perf/x86/rapl: Add AMD Fam19h RAPL support
Family 19h RAPL support did not change from Family 17h; extend
the existing Fam17h support to work on Family 19h too.
Signed-off-by: Kim Phillips
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
---
arch/x86/events/rapl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
index 67b411f7e8c4..7c0120e2e957 100644
--- a/arch/x86/events/rapl.c
+++ b/arch/x86/events/rapl.c
@@ -815,6 +815,7 @@ static const struct x86_cpu_id rapl_model_match[]
__initconst = {
X86_MATCH_INTEL_FAM6_MODEL(SAPPHIRERAPIDS_X,_spr),
X86_MATCH_VENDOR_FAM(AMD, 0x17, _amd_fam17h),
X86_MATCH_VENDOR_FAM(HYGON, 0x18, _amd_fam17h),
+ X86_MATCH_VENDOR_FAM(AMD, 0x19, _amd_fam17h),
{},
};
MODULE_DEVICE_TABLE(x86cpu, rapl_model_match);
--
2.27.0
[PATCH 6/7] perf/x86/amd/ibs: Support 27-bit extended Op/cycle counter
IBS hardware with the OpCntExt feature gets a 7-bit wider internal
counter. Both the maximum and current count bitfields in the
IBS_OP_CTL register are extended to support reading and writing it.
No changes are necessary to the driver for handling the extra
contiguous current count bits (IbsOpCurCnt), as the driver already
passes through 32 bits of that field. However, the driver has to do
some extra bit manipulation when converting from a period to the
non-contiguous (although conveniently aligned) extra bits in the
IbsOpMaxCnt bitfield.
This decreases IBS Op interrupt overhead when the period is over
1,048,560 (0x0), which would previously activate the driver's
software counter. That threshold is now 134,217,712 (0x7f0).
Signed-off-by: Kim Phillips
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
---
arch/x86/events/amd/ibs.c | 42 +++
arch/x86/include/asm/perf_event.h | 1 +
2 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 609ae7d165c1..3a32c523cc12 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -339,10 +339,13 @@ static u64 get_ibs_op_count(u64 config)
* and the lower 7 bits of CurCnt are randomized.
* Otherwise CurCnt has the full 27-bit current counter value.
*/
- if (config & IBS_OP_VAL)
+ if (config & IBS_OP_VAL) {
count = (config & IBS_OP_MAX_CNT) << 4;
- else if (ibs_caps & IBS_CAPS_RDWROPCNT)
+ if (ibs_caps & IBS_CAPS_OPCNTEXT)
+ count += config & IBS_OP_MAX_CNT_EXT_MASK;
+ } else if (ibs_caps & IBS_CAPS_RDWROPCNT) {
count = (config & IBS_OP_CUR_CNT) >> 32;
+ }
return count;
}
@@ -405,7 +408,7 @@ static void perf_ibs_start(struct perf_event *event, int
flags)
struct hw_perf_event *hwc = >hw;
struct perf_ibs *perf_ibs = container_of(event->pmu, struct perf_ibs,
pmu);
struct cpu_perf_ibs *pcpu = this_cpu_ptr(perf_ibs->pcpu);
- u64 period;
+ u64 period, config = 0;
if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
return;
@@ -414,13 +417,19 @@ static void perf_ibs_start(struct perf_event *event, int
flags)
hwc->state = 0;
perf_ibs_set_period(perf_ibs, hwc, );
+ if (perf_ibs == _ibs_op && (ibs_caps & IBS_CAPS_OPCNTEXT)) {
+ config |= period & IBS_OP_MAX_CNT_EXT_MASK;
+ period &= ~IBS_OP_MAX_CNT_EXT_MASK;
+ }
+ config |= period >> 4;
+
/*
* Set STARTED before enabling the hardware, such that a subsequent NMI
* must observe it.
*/
set_bit(IBS_STARTED,pcpu->state);
clear_bit(IBS_STOPPING, pcpu->state);
- perf_ibs_enable_event(perf_ibs, hwc, period >> 4);
+ perf_ibs_enable_event(perf_ibs, hwc, config);
perf_event_update_userpage(event);
}
@@ -588,7 +597,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
struct perf_ibs_data ibs_data;
int offset, size, check_rip, offset_max, throttle = 0;
unsigned int msr;
- u64 *buf, *config, period;
+ u64 *buf, *config, period, new_config = 0;
if (!test_bit(IBS_STARTED, pcpu->state)) {
fail:
@@ -683,13 +692,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
if (throttle) {
perf_ibs_stop(event, 0);
} else {
- period >>= 4;
-
- if ((ibs_caps & IBS_CAPS_RDWROPCNT) &&
- (*config & IBS_OP_CNT_CTL))
- period |= *config & IBS_OP_CUR_CNT_RAND;
+ if (perf_ibs == _ibs_op) {
+ if (ibs_caps & IBS_CAPS_OPCNTEXT) {
+ new_config = period & IBS_OP_MAX_CNT_EXT_MASK;
+ period &= ~IBS_OP_MAX_CNT_EXT_MASK;
+ }
+ if ((ibs_caps & IBS_CAPS_RDWROPCNT) && (*config &
IBS_OP_CNT_CTL))
+ new_config |= *config & IBS_OP_CUR_CNT_RAND;
+ }
+ new_config |= period >> 4;
- perf_ibs_enable_event(perf_ibs, hwc, period);
+ perf_ibs_enable_event(perf_ibs, hwc, new_config);
}
perf_event_update_userpage(event);
@@ -756,6 +769,13 @@ static __init void perf_event_ibs_init(void)
perf_ibs_op.config_mask |= IBS_OP
[PATCH 3/7] arch/x86/amd/ibs: Fix re-arming IBS Fetch
Stephane Eranian found a bug in that IBS' current Fetch counter was not
being reset when the driver would write the new value to clear it along
with the enable bit set, and found that adding an MSR write that would
first disable IBS Fetch would make IBS Fetch reset its current count.
Indeed, the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54 - Sep 12,
2019 states "The periodic fetch counter is set to IbsFetchCnt [...] when
IbsFetchEn is changed from 0 to 1."
Explicitly set IbsFetchEn to 0 and then to 1 when re-enabling IBS Fetch,
so the driver properly resets the internal counter to 0 and IBS
Fetch starts counting again.
It is not clear what versions of IBS hardware need IbsFetchEn explicitly
zeroed and which historically may not have, so now make the driver
always do it.
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
arch/x86/events/amd/ibs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 26c36357c4c9..8ddce7dd2c4a 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -363,7 +363,14 @@ perf_ibs_event_update(struct perf_ibs *perf_ibs, struct
perf_event *event,
static inline void perf_ibs_enable_event(struct perf_ibs *perf_ibs,
struct hw_perf_event *hwc, u64 config)
{
- wrmsrl(hwc->config_base, hwc->config | config | perf_ibs->enable_mask);
+ u64 _config = (hwc->config | config) & ~perf_ibs->enable_mask;
+
+ /* The periodic fetch counter is set when IbsFetchEn is changed from 0
to 1 */
+ if (perf_ibs == _ibs_fetch)
+ wrmsrl(hwc->config_base, _config);
+
+ _config |= perf_ibs->enable_mask;
+ wrmsrl(hwc->config_base, _config);
}
/*
--
2.27.0
[PATCH 2/7] perf/x86/amd: Fix sampling Large Increment per Cycle events
Commit 5738891229a2 ("perf/x86/amd: Add support for Large Increment
per Cycle Events") mistakenly zeroes the upper 16 bits of the count
in set_period(). That's fine for counting with perf stat, but not
sampling with perf record when only Large Increment events are being
sampled. To enable sampling, we sign extend the upper 16 bits of the
merged counter pair as described in the Family 17h PPRs:
"Software wanting to preload a value to a merged counter pair writes the
high-order 16-bit value to the low-order 16 bits of the odd counter and
then writes the low-order 48-bit value to the even counter. Reading the
even counter of the merged counter pair returns the full 64-bit value."
Fixes: 5738891229a2 ("perf/x86/amd: Add support for Large Increment per Cycle
Events")
Signed-off-by: Kim Phillips
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
arch/x86/events/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 1cbf57dc2ac8..2fdc211e3e56 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1284,11 +1284,11 @@ int x86_perf_event_set_period(struct perf_event *event)
wrmsrl(hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);
/*
-* Clear the Merge event counter's upper 16 bits since
+* Sign extend the Merge event counter's upper 16 bits since
* we currently declare a 48-bit counter width
*/
if (is_counter_pair(hwc))
- wrmsrl(x86_pmu_event_addr(idx + 1), 0);
+ wrmsrl(x86_pmu_event_addr(idx + 1), 0x);
/*
* Due to erratum on certan cpu we need
--
2.27.0
[PATCH 4/7] perf/x86/amd/ibs: Don't include randomized bits in get_ibs_op_count()
get_ibs_op_count() adds hardware's current count (IbsOpCurCnt) bits
to its count regardless of hardware's valid status.
According to the PPR for AMD Family 17h Model 31h B0 55803 Rev 0.54,
if the counter rolls over, valid status is set, and the lower 7 bits
of IbsOpCurCnt are randomized by hardware.
Don't include those bits in the driver's event count.
Signed-off-by: Kim Phillips
Fixes: 8b1e13638d46 ("perf/x86-ibs: Fix usage of IBS op current count")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
arch/x86/events/amd/ibs.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 8ddce7dd2c4a..ffeb24d31c3d 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -334,11 +334,15 @@ static u64 get_ibs_op_count(u64 config)
{
u64 count = 0;
+ /*
+* If the internal 27-bit counter rolled over, the count is MaxCnt
+* and the lower 7 bits of CurCnt are randomized.
+* Otherwise CurCnt has the full 27-bit current counter value.
+*/
if (config & IBS_OP_VAL)
- count += (config & IBS_OP_MAX_CNT) << 4; /* cnt rolled over */
-
- if (ibs_caps & IBS_CAPS_RDWROPCNT)
- count += (config & IBS_OP_CUR_CNT) >> 32;
+ count = (config & IBS_OP_MAX_CNT) << 4;
+ else if (ibs_caps & IBS_CAPS_RDWROPCNT)
+ count = (config & IBS_OP_CUR_CNT) >> 32;
return count;
}
--
2.27.0
[PATCH 5/7] perf/x86/amd/ibs: Fix raw sample data accumulation
Neither IbsBrTarget nor OPDATA4 are populated in IBS Fetch mode.
Don't accumulate them into raw sample user data in that case.
Also, in Fetch mode, add saving the IBS Fetch Control Extended MSR.
Technically, there is an ABI change here with respect to the IBS raw
sample data format. I don't see any perf driver version information
being included in perf.data file headers, but, existing users can detect
whether the size of the sample record has reduced by 8 bytes to
determine whether the IBS driver has this fix.
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
Fixes: 904cb3677f3a ("perf/x86/amd/ibs: Update IBS MSRs and feature
definitions")
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
arch/x86/events/amd/ibs.c| 26 --
arch/x86/include/asm/msr-index.h | 1 +
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index ffeb24d31c3d..609ae7d165c1 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -637,18 +637,24 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
perf_ibs->offset_max,
offset + 1);
} while (offset < offset_max);
+ /*
+* Read IbsBrTarget, IbsOpData4, and IbsExtdCtl separately
+* depending on their availability.
+* Can't add to offset_max as they are staggered
+*/
if (event->attr.sample_type & PERF_SAMPLE_RAW) {
- /*
-* Read IbsBrTarget and IbsOpData4 separately
-* depending on their availability.
-* Can't add to offset_max as they are staggered
-*/
- if (ibs_caps & IBS_CAPS_BRNTRGT) {
- rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++);
- size++;
+ if (perf_ibs == _ibs_op) {
+ if (ibs_caps & IBS_CAPS_BRNTRGT) {
+ rdmsrl(MSR_AMD64_IBSBRTARGET, *buf++);
+ size++;
+ }
+ if (ibs_caps & IBS_CAPS_OPDATA4) {
+ rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++);
+ size++;
+ }
}
- if (ibs_caps & IBS_CAPS_OPDATA4) {
- rdmsrl(MSR_AMD64_IBSOPDATA4, *buf++);
+ if (perf_ibs == _ibs_fetch && (ibs_caps &
IBS_CAPS_FETCHCTLEXTD)) {
+ rdmsrl(MSR_AMD64_ICIBSEXTDCTL, *buf++);
size++;
}
}
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 2859ee4f39a8..b08c8a2afc0e 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -464,6 +464,7 @@
#define MSR_AMD64_IBSOP_REG_MASK ((1UL<
[PATCH 1/7 RESEND] perf/amd/uncore: Set all slices and threads to restore perf stat -a behaviour
Commit 2f217d58a8a0 ("perf/x86/amd/uncore: Set the thread mask for
F17h L3 PMCs") inadvertently changed the uncore driver's behaviour
wrt perf tool invocations with or without a CPU list, specified with
-C / --cpu=.
Change the behaviour of the driver to assume the former all-cpu (-a)
case, which is the more commonly desired default. This fixes
'-a -A' invocations without explicit cpu lists (-C) to not count
L3 events only on behalf of the first thread of the first core
in the L3 domain.
BEFORE:
Activity performed by the first thread of the last core (CPU#43) in
CPU#40's L3 domain is not reported by CPU#40:
sudo perf stat -a -A -e l3_request_g1.caching_l3_cache_accesses taskset -c 43
perf bench mem memcpy -s 32mb -l 100 -f default
...
CPU36 21,835 l3_request_g1.caching_l3_cache_accesses
CPU40 87,066 l3_request_g1.caching_l3_cache_accesses
CPU44 17,360 l3_request_g1.caching_l3_cache_accesses
...
AFTER:
The L3 domain activity is now reported by CPU#40:
sudo perf stat -a -A -e l3_request_g1.caching_l3_cache_accesses taskset -c 43
perf bench mem memcpy -s 32mb -l 100 -f default
...
CPU36354,891 l3_request_g1.caching_l3_cache_accesses
CPU40 1,780,870 l3_request_g1.caching_l3_cache_accesses
CPU44315,062 l3_request_g1.caching_l3_cache_accesses
...
Reported-by: Stephane Eranian
Signed-off-by: Kim Phillips
Fixes: 2f217d58a8a0 ("perf/x86/amd/uncore: Set the thread mask for F17h L3
PMCs")
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: "H. Peter Anvin"
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Michael Petlan
Cc: Namhyung Kim
Cc: LKML
Cc: x86
Cc: sta...@vger.kernel.org
---
Original submission:
https://lore.kernel.org/lkml/20200323233159.19601-1-kim.phill...@amd.com/
arch/x86/events/amd/uncore.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 76400c052b0e..e7e61c8b56bd 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -181,28 +181,16 @@ static void amd_uncore_del(struct perf_event *event, int
flags)
}
/*
- * Convert logical CPU number to L3 PMC Config ThreadMask format
+ * Return a full thread and slice mask until per-CPU is
+ * properly supported.
*/
-static u64 l3_thread_slice_mask(int cpu)
+static u64 l3_thread_slice_mask(void)
{
- u64 thread_mask, core = topology_core_id(cpu);
- unsigned int shift, thread = 0;
+ if (boot_cpu_data.x86 <= 0x18)
+ return AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK;
- if (topology_smt_supported() && !topology_is_primary_thread(cpu))
- thread = 1;
-
- if (boot_cpu_data.x86 <= 0x18) {
- shift = AMD64_L3_THREAD_SHIFT + 2 * (core % 4) + thread;
- thread_mask = BIT_ULL(shift);
-
- return AMD64_L3_SLICE_MASK | thread_mask;
- }
-
- core = (core << AMD64_L3_COREID_SHIFT) & AMD64_L3_COREID_MASK;
- shift = AMD64_L3_THREAD_SHIFT + thread;
- thread_mask = BIT_ULL(shift);
-
- return AMD64_L3_EN_ALL_SLICES | core | thread_mask;
+ return AMD64_L3_EN_ALL_SLICES | AMD64_L3_EN_ALL_CORES |
+ AMD64_L3_F19H_THREAD_MASK;
}
static int amd_uncore_event_init(struct perf_event *event)
@@ -232,7 +220,7 @@ static int amd_uncore_event_init(struct perf_event *event)
* For other events, the two fields do not affect the count.
*/
if (l3_mask && is_llc_event(event))
- hwc->config |= l3_thread_slice_mask(event->cpu);
+ hwc->config |= l3_thread_slice_mask();
uncore = event_to_amd_uncore(event);
if (!uncore)
--
2.27.0
Re: [PATCH 13/13] cpufreq: amd_freq_sensitivity: Remove unused ID structs
On 7/14/20 4:02 PM, Lee Jones wrote:
> On Tue, 14 Jul 2020, Kim Phillips wrote:
>> On 7/14/20 9:50 AM, Lee Jones wrote:
>>> Can't see them being used anywhere and the compiler doesn't complain
>>> that they're missing, so ...
>>>
>>> Fixes the following W=1 kernel build warning(s):
>>>
>>> drivers/cpufreq/amd_freq_sensitivity.c:147:32: warning:
>>> ‘amd_freq_sensitivity_ids’ defined but not used [-Wunused-const-variable=]
>>> 147 | static const struct x86_cpu_id amd_freq_sensitivity_ids[] = {
>>> | ^~~~
>>>
>>> Cc: Jacob Shin
>>> Signed-off-by: Lee Jones
>>> ---
>>
>> Same comment as for patch 9/13: these are used automatic module loading.
>
> How does that work?
>
> Could you point me to the code which handles that please?
It's MODULE_DEVICE_TABLE magic.
Kim
Re: [PATCH 13/13] cpufreq: amd_freq_sensitivity: Remove unused ID structs
On 7/14/20 9:50 AM, Lee Jones wrote:
> Can't see them being used anywhere and the compiler doesn't complain
> that they're missing, so ...
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/cpufreq/amd_freq_sensitivity.c:147:32: warning:
> ‘amd_freq_sensitivity_ids’ defined but not used [-Wunused-const-variable=]
> 147 | static const struct x86_cpu_id amd_freq_sensitivity_ids[] = {
> | ^~~~
>
> Cc: Jacob Shin
> Signed-off-by: Lee Jones
> ---
Same comment as for patch 9/13: these are used automatic module loading.
Kim
Re: [PATCH] perf/x86/rapl: fix rapl config variable bug
On 5/28/20 3:16 PM, Stephane Eranian wrote:
> This patch fixes a bug introduced by:
>
> commit fd3ae1e1587d6 ("perf/x86/rapl: Move RAPL support to common x86 code")
>
> The Kconfig variable name was wrong. It was missing the CONFIG_ prefix.
>
> Signed-off-by: Stephane Eranian
>
> ---
Tested-by: Kim Phillips
Thanks,
Kim
[tip: x86/cpu] x86/cpu/amd: Make erratum #1054 a legacy erratum
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: e2abfc0448a46d8a137505aa180caf14070ec535
Gitweb:
https://git.kernel.org/tip/e2abfc0448a46d8a137505aa180caf14070ec535
Author:Kim Phillips
AuthorDate:Fri, 17 Apr 2020 09:33:56 -05:00
Committer: Borislav Petkov
CommitterDate: Thu, 07 May 2020 17:30:14 +02:00
x86/cpu/amd: Make erratum #1054 a legacy erratum
Commit
21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired
counter IRPERF")
mistakenly added erratum #1054 as an OS Visible Workaround (OSVW) ID 0.
Erratum #1054 is not OSVW ID 0 [1], so make it a legacy erratum.
There would never have been a false positive on older hardware that
has OSVW bit 0 set, since the IRPERF feature was not available.
However, save a couple of RDMSR executions per thread, on modern
system configurations that correctly set non-zero values in their
OSVW_ID_Length MSRs.
[1] Revision Guide for AMD Family 17h Models 00h-0Fh Processors. The
revision guide is available from the bugzilla link below.
Fixes: 21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired
counter IRPERF")
Reported-by: Andrew Cooper
Signed-off-by: Kim Phillips
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20200417143356.26054-1-kim.phill...@amd.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
---
arch/x86/kernel/cpu/amd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 547ad7b..8a1bdda 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1142,8 +1142,7 @@ static const int amd_erratum_383[] =
/* #1054: Instructions Retired Performance Counter May Be Inaccurate */
static const int amd_erratum_1054[] =
- AMD_OSVW_ERRATUM(0, AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
-
+ AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
{
[tip: x86/cpu] x86/cpu/amd: Make erratum #1054 a legacy erratum
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: 3e2c1fd2022ccce96b6a05a6ab519d65769ee320
Gitweb:
https://git.kernel.org/tip/3e2c1fd2022ccce96b6a05a6ab519d65769ee320
Author:Kim Phillips
AuthorDate:Fri, 17 Apr 2020 09:33:56 -05:00
Committer: Borislav Petkov
CommitterDate: Wed, 06 May 2020 19:18:24 +02:00
x86/cpu/amd: Make erratum #1054 a legacy erratum
Commit
21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired
counter IRPERF")
mistakenly added erratum #1054 as an OS Visible Workaround (OSVW) ID 0.
Erratum #1054 is not OSVW ID 0 [1], so make it a legacy erratum.
There would never have been a false positive on older hardware that
has OSVW bit 0 set, since the IRPERF feature was not available.
However, save a couple of RDMSR executions per thread, on modern
system configurations that correctly set non-zero values in their
OSVW_ID_Length MSRs.
[1] Revision Guide for AMD Family 17h Models 00h-0Fh Processors. The
revision guide is available from the bugzilla link below.
Fixes: 21b5ee59ef18 ("x86/cpu/amd: Enable the fixed Instructions Retired
counter IRPERF")
Reported-by: Andrew Cooper
Signed-off-by: Kim Phillips
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20200417143356.26054-1-kim.phill...@amd.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 547ad7b..6437381 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1142,7 +1142,7 @@ static const int amd_erratum_383[] =
/* #1054: Instructions Retired Performance Counter May Be Inaccurate */
static const int amd_erratum_1054[] =
- AMD_OSVW_ERRATUM(0, AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
+ AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x17, 0, 0, 0x2f, 0xf));
static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum)
[PATCH 2/2] perf/x86/amd/ibs: handle erratum #420 only on the affected CPU family (10h)
This saves us writing the IBS control MSR twice when disabling the
event.
I searched revision guides for all families since 10h, and did not
find occurrence of erratum #420, nor anything remotely similar:
so we isolate the secondary MSR write to family 10h only.
Also unconditionally update the count mask for IBS Op implementations
that have read & writeable current count (CurCnt) fields in addition
to the MaxCnt field. These bits were reserved on prior
implementations, and therefore shouldn't have negative impact.
Signed-off-by: Kim Phillips
Fixes: c9574fe0bdb9 ("perf/x86-ibs: Implement workaround for IBS erratum #420")
Cc: sta...@vger.kernel.org
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/events/amd/ibs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 98ba21a588a1..26c36357c4c9 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -377,7 +377,8 @@ static inline void perf_ibs_disable_event(struct perf_ibs
*perf_ibs,
struct hw_perf_event *hwc, u64 config)
{
config &= ~perf_ibs->cnt_mask;
- wrmsrl(hwc->config_base, config);
+ if (boot_cpu_data.x86 == 0x10)
+ wrmsrl(hwc->config_base, config);
config &= ~perf_ibs->enable_mask;
wrmsrl(hwc->config_base, config);
}
@@ -553,7 +554,8 @@ static struct perf_ibs perf_ibs_op = {
},
.msr= MSR_AMD64_IBSOPCTL,
.config_mask= IBS_OP_CONFIG_MASK,
- .cnt_mask = IBS_OP_MAX_CNT,
+ .cnt_mask = IBS_OP_MAX_CNT | IBS_OP_CUR_CNT |
+ IBS_OP_CUR_CNT_RAND,
.enable_mask= IBS_OP_ENABLE,
.valid_mask = IBS_OP_VAL,
.max_period = IBS_OP_MAX_CNT << 4,
--
2.23.0
[PATCH 1/2] perf/x86/amd/ibs: Fix reading of the IBS OpData register and thus precise RIP validity
The loop that reads all the IBS MSRs into *buf stopped one MSR short of
reading the IbsOpData register, which contains the RipInvalid status bit.
Fix the offset_max assignment so the MSR gets read, so the RIP invalid
evaluation is based on what the IBS h/w output, instead of what was
left in memory.
Signed-off-by: Kim Phillips
Fixes: d47e8238cd76 ("perf/x86-ibs: Take instruction pointer from ibs sample")
Cc: sta...@vger.kernel.org
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/events/amd/ibs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 5b35b7ea5d72..98ba21a588a1 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -614,7 +614,7 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
if (event->attr.sample_type & PERF_SAMPLE_RAW)
offset_max = perf_ibs->offset_max;
else if (check_rip)
- offset_max = 2;
+ offset_max = 3;
else
offset_max = 1;
do {
--
2.23.0
[PATCH 5/5] perf list: specify metrics are to be used with -M
Output of 'perf list metrics' before:
$ perf list metrics
List of pre-defined events (to be used in -e):
Metrics:
C2_Pkg_Residency
[C2 residency percent per package]
...
This misleads the uninitiated user to try:
$ perf stat -e C2_Pkg_Residency
which gets:
event syntax error: 'C2_Pkg_Residency'
\___ parser error
Run 'perf list' for a list of valid events
Explicitly clarify that metrics and metricgroups are meant to
be used with -M, and correct the grammar for the -e equivalent
statement.
Output of 'perf list metrics' after:
$ perf list metrics
List of pre-defined events (to be used with -e):
Metrics (to be used with -M):
C2_Pkg_Residency
[C2 residency percent per package]
...
Signed-off-by: Kim Phillips
Cc: Janakarajan Natarajan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Martin Liska
Cc: Luke Mujica
Cc: Jin Yao
Cc: Kan Liang
Cc: linux-kernel@vger.kernel.org
Cc: linux-perf-us...@vger.kernel.org
---
tools/perf/builtin-list.c | 2 +-
tools/perf/util/metricgroup.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 08e62ae9d37e..be8e878aa556 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -51,7 +51,7 @@ int cmd_list(int argc, const char **argv)
setup_pager();
if (!raw_dump && pager_in_use())
- printf("\nList of pre-defined events (to be used in -e):\n\n");
+ printf("\nList of pre-defined events (to be used with
-e):\n\n");
if (argc == 0) {
print_events(NULL, raw_dump, !desc_flag, long_desc_flag,
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index a7c0424dbda3..f116848be9f7 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -377,9 +377,10 @@ void metricgroup__print(bool metrics, bool metricgroups,
char *filter,
}
if (metricgroups && !raw)
- printf("\nMetric Groups:\n\n");
+ printf("\nMetric Groups");
else if (metrics && !raw)
- printf("\nMetrics:\n\n");
+ printf("\nMetrics");
+ printf(" (to be used with -M):\n\n");
for (node = rb_first_cached(); node; node = next) {
struct mep *me = container_of(node, struct mep, nd);
--
2.23.0
[PATCH 2/5] perf vendor events amd: remove redundant '['
Remove the redundant '['.
perf list output before:
ex_ret_brn
[[Retired Branch Instructions]
perf list output after:
ex_ret_brn
[Retired Branch Instructions]
Signed-off-by: Kim Phillips
Cc: Janakarajan Natarajan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Martin Liska
Cc: Luke Mujica
Cc: Jin Yao
Cc: Kan Liang
Cc: linux-kernel@vger.kernel.org
Cc: linux-perf-us...@vger.kernel.org
Fixes: 98c07a8f74f8 ("perf vendor events amd: perf PMU events for AMD Family
17h")
---
tools/perf/pmu-events/arch/x86/amdfam17h/core.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/pmu-events/arch/x86/amdfam17h/core.json
b/tools/perf/pmu-events/arch/x86/amdfam17h/core.json
index 7b285b0a7f35..1079544eeed5 100644
--- a/tools/perf/pmu-events/arch/x86/amdfam17h/core.json
+++ b/tools/perf/pmu-events/arch/x86/amdfam17h/core.json
@@ -13,7 +13,7 @@
{
"EventName": "ex_ret_brn",
"EventCode": "0xc2",
-"BriefDescription": "[Retired Branch Instructions.",
+"BriefDescription": "Retired Branch Instructions.",
"PublicDescription": "The number of branch instructions retired. This
includes all types of architectural control flow changes, including exceptions
and interrupts."
},
{
--
2.23.0
[PATCH 3/5] perf vendor events: minor fixes to the README
Some grammatical fixes, and updates to some path references that have since changed. Signed-off-by: Kim Phillips Cc: Janakarajan Natarajan Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Cc: Borislav Petkov Cc: Martin Liska Cc: Luke Mujica Cc: Jin Yao Cc: Kan Liang Cc: linux-kernel@vger.kernel.org Cc: linux-perf-us...@vger.kernel.org --- tools/perf/pmu-events/README | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tools/perf/pmu-events/README b/tools/perf/pmu-events/README index e62b09b6a844..de7efa2cebd1 100644 --- a/tools/perf/pmu-events/README +++ b/tools/perf/pmu-events/README @@ -30,9 +30,9 @@ the topic. Eg: "Floating-point.json". All the topic JSON files for a CPU model/family should be in a separate sub directory. Thus for the Silvermont X86 CPU: - $ ls tools/perf/pmu-events/arch/x86/Silvermont_core - Cache.json Memory.json Virtual-Memory.json - Frontend.json Pipeline.json + $ ls tools/perf/pmu-events/arch/x86/silvermont + cache.json memory.jsonvirtual-memory.json + frontend.json pipeline.json The JSONs folder for a CPU model/family may be placed in the root arch folder, or may be placed in a vendor sub-folder under the arch folder @@ -94,7 +94,7 @@ users to specify events by their name: where 'pm_1plus_ppc_cmpl' is a Power8 PMU event. -However some errors in processing may cause the perf build to fail. +However some errors in processing may cause the alias build to fail. Mapfile format === @@ -119,7 +119,7 @@ where: Header line The header line is the first line in the file, which is - always _IGNORED_. It can empty. + always _IGNORED_. It can be empty. CPUID: CPUID is an arch-specific char string, that can be used @@ -138,15 +138,15 @@ where: files, relative to the directory containing the mapfile.csv Type: - indicates whether the events or "core" or "uncore" events. + indicates whether the events are "core" or "uncore" events. Eg: - $ grep Silvermont tools/perf/pmu-events/arch/x86/mapfile.csv - GenuineIntel-6-37,V13,Silvermont_core,core - GenuineIntel-6-4D,V13,Silvermont_core,core - GenuineIntel-6-4C,V13,Silvermont_core,core + $ grep silvermont tools/perf/pmu-events/arch/x86/mapfile.csv + GenuineIntel-6-37,v13,silvermont,core + GenuineIntel-6-4D,v13,silvermont,core + GenuineIntel-6-4C,v13,silvermont,core i.e the three CPU models use the JSON files (i.e PMU events) listed - in the directory 'tools/perf/pmu-events/arch/x86/Silvermont_core'. + in the directory 'tools/perf/pmu-events/arch/x86/silvermont'. -- 2.23.0
[PATCH 4/5] perf list: allow plurals for metric, metricgroup
Enhance usability by allowing the same plurality used in the output title, for
the command line parameter.
BEFORE, perf deceitfully acts as if there are no metrics to be had:
$ perf list metrics
List of pre-defined events (to be used in -e):
Metric Groups:
$
But singular 'metric' shows a list of metrics:
$ perf list metric
List of pre-defined events (to be used in -e):
Metrics:
IPC
[Instructions Per Cycle (per logical thread)]
UPI
[Uops Per Instruction]
AFTER, when asking for 'metrics', we actually see the metrics get listed:
$ perf list metrics
List of pre-defined events (to be used in -e):
Metrics:
IPC
[Instructions Per Cycle (per logical thread)]
UPI
[Uops Per Instruction]
Signed-off-by: Kim Phillips
Cc: Janakarajan Natarajan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Martin Liska
Cc: Luke Mujica
Cc: Jin Yao
Cc: Kan Liang
Cc: linux-kernel@vger.kernel.org
Cc: linux-perf-us...@vger.kernel.org
Fixes: 71b0acce78d1 ("perf list: Add metric groups to perf list")
---
tools/perf/builtin-list.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index e290f6b348d8..08e62ae9d37e 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -81,9 +81,9 @@ int cmd_list(int argc, const char **argv)
long_desc_flag, details_flag);
else if (strcmp(argv[i], "sdt") == 0)
print_sdt_events(NULL, NULL, raw_dump);
- else if (strcmp(argv[i], "metric") == 0)
+ else if (strcmp(argv[i], "metric") == 0 || strcmp(argv[i],
"metrics") == 0)
metricgroup__print(true, false, NULL, raw_dump,
details_flag);
- else if (strcmp(argv[i], "metricgroup") == 0)
+ else if (strcmp(argv[i], "metricgroup") == 0 || strcmp(argv[i],
"metricgroups") == 0)
metricgroup__print(false, true, NULL, raw_dump,
details_flag);
else if ((sep = strchr(argv[i], ':')) != NULL) {
int sep_idx;
--
2.23.0
[PATCH 1/5] perf vendor events amd: add L3 cache events for Family 17h
Allow users to symbolically specify L3 events for Family 17h processors
using the existing AMD Uncore driver.
Source of events descriptions are from section 2.1.15.4.1
"L3 Cache PMC Events" of the latest Family 17h PPR, available here:
https://www.amd.com/system/files/TechDocs/55570-B1_PUB.zip
Only BriefDescriptions added, since they show with and without
the -v and --details flags.
Tested with:
# perf stat -e
l3_request_g1.caching_l3_cache_accesses,amd_l3/event=0x01,umask=0x80/,l3_comb_clstr_state.request_miss,amd_l3/event=0x06,umask=0x01/
perf bench mem memcpy -s 4mb -l 100 -f default
...
7,006,831 l3_request_g1.caching_l3_cache_accesses
7,006,830 amd_l3/event=0x01,umask=0x80/
366,530 l3_comb_clstr_state.request_miss
366,568 amd_l3/event=0x06,umask=0x01/
Signed-off-by: Kim Phillips
Cc: Janakarajan Natarajan
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Borislav Petkov
Cc: Martin Liska
Cc: Luke Mujica
Cc: Jin Yao
Cc: Kan Liang
Cc: linux-kernel@vger.kernel.org
Cc: linux-perf-us...@vger.kernel.org
---
.../pmu-events/arch/x86/amdfam17h/cache.json | 42 +++
tools/perf/pmu-events/jevents.c | 1 +
2 files changed, 43 insertions(+)
diff --git a/tools/perf/pmu-events/arch/x86/amdfam17h/cache.json
b/tools/perf/pmu-events/arch/x86/amdfam17h/cache.json
index fad4af9142cb..6221a840fcea 100644
--- a/tools/perf/pmu-events/arch/x86/amdfam17h/cache.json
+++ b/tools/perf/pmu-events/arch/x86/amdfam17h/cache.json
@@ -283,5 +283,47 @@
"BriefDescription": "Total cycles spent with one or more fill requests in
flight from L2.",
"PublicDescription": "Total cycles spent with one or more fill requests in
flight from L2.",
"UMask": "0x1"
+ },
+ {
+"EventName": "l3_request_g1.caching_l3_cache_accesses",
+"EventCode": "0x01",
+"BriefDescription": "Caching: L3 cache accesses",
+"UMask": "0x80",
+"Unit": "L3PMC"
+ },
+ {
+"EventName": "l3_lookup_state.all_l3_req_typs",
+"EventCode": "0x04",
+"BriefDescription": "All L3 Request Types",
+"UMask": "0xff",
+"Unit": "L3PMC"
+ },
+ {
+"EventName": "l3_comb_clstr_state.other_l3_miss_typs",
+"EventCode": "0x06",
+"BriefDescription": "Other L3 Miss Request Types",
+"UMask": "0xfe",
+"Unit": "L3PMC"
+ },
+ {
+"EventName": "l3_comb_clstr_state.request_miss",
+"EventCode": "0x06",
+"BriefDescription": "L3 cache misses",
+"UMask": "0x01",
+"Unit": "L3PMC"
+ },
+ {
+"EventName": "xi_sys_fill_latency",
+"EventCode": "0x90",
+"BriefDescription": "L3 Cache Miss Latency. Total cycles for all
transactions divided by 16. Ignores SliceMask and ThreadMask.",
+"UMask": "0x00",
+"Unit": "L3PMC"
+ },
+ {
+"EventName": "xi_ccx_sdp_req1.all_l3_miss_req_typs",
+"EventCode": "0x9a",
+"BriefDescription": "All L3 Miss Request Types. Ignores SliceMask and
ThreadMask.",
+"UMask": "0x3f",
+"Unit": "L3PMC"
}
]
diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
index d413761621b0..9e37287da924 100644
--- a/tools/perf/pmu-events/jevents.c
+++ b/tools/perf/pmu-events/jevents.c
@@ -239,6 +239,7 @@ static struct map {
{ "hisi_sccl,ddrc", "hisi_sccl,ddrc" },
{ "hisi_sccl,hha", "hisi_sccl,hha" },
{ "hisi_sccl,l3c", "hisi_sccl,l3c" },
+ { "L3PMC", "amd_l3" },
{}
};
--
2.23.0
[tip: perf/urgent] perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 0f4cd769c410e2285a4e9873a684d90423f03090
Gitweb:
https://git.kernel.org/tip/0f4cd769c410e2285a4e9873a684d90423f03090
Author:Kim Phillips
AuthorDate:Mon, 26 Aug 2019 14:57:30 -05:00
Committer: Peter Zijlstra
CommitterDate: Fri, 30 Aug 2019 14:27:47 +02:00
perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops
When counting dispatched micro-ops with cnt_ctl=1, in order to prevent
sample bias, IBS hardware preloads the least significant 7 bits of
current count (IbsOpCurCnt) with random values, such that, after the
interrupt is handled and counting resumes, the next sample taken
will be slightly perturbed.
The current count bitfield is in the IBS execution control h/w register,
alongside the maximum count field.
Currently, the IBS driver writes that register with the maximum count,
leaving zeroes to fill the current count field, thereby overwriting
the random bits the hardware preloaded for itself.
Fix the driver to actually retain and carry those random bits from the
read of the IBS control register, through to its write, instead of
overwriting the lower current count bits with zeroes.
Tested with:
perf record -c 11 -e ibs_op/cnt_ctl=1/pp -a -C 0 taskset -c 0
'perf annotate' output before:
15.70 65: addsd %xmm0,%xmm1
17.30add $0x1,%rax
15.88cmp %rdx,%rax
je82
17.32 72: test $0x1,%al
jne 7c
7.52movapd%xmm1,%xmm0
5.90jmp 65
8.23 7c: sqrtsd%xmm1,%xmm0
12.15jmp 65
'perf annotate' output after:
16.63 65: addsd %xmm0,%xmm1
16.82add $0x1,%rax
16.81cmp %rdx,%rax
je82
16.69 72: test $0x1,%al
jne 7c
8.30movapd%xmm1,%xmm0
8.13jmp 65
8.24 7c: sqrtsd%xmm1,%xmm0
8.39jmp 65
Tested on Family 15h and 17h machines.
Machines prior to family 10h Rev. C don't have the RDWROPCNT capability,
and have the IbsOpCurCnt bitfield reserved, so this patch shouldn't
affect their operation.
It is unknown why commit db98c5faf8cb ("perf/x86: Implement 64-bit
counter support for IBS") ignored the lower 4 bits of the IbsOpCurCnt
field; the number of preloaded random bits has always been 7, AFAICT.
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc: "Arnaldo Carvalho de Melo"
Cc:
Cc: Ingo Molnar
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Thomas Gleixner
Cc: "Borislav Petkov"
Cc: Stephane Eranian
Cc: Alexander Shishkin
Cc: "Namhyung Kim"
Cc: "H. Peter Anvin"
Link: https://lkml.kernel.org/r/20190826195730.30614-1-kim.phill...@amd.com
---
arch/x86/events/amd/ibs.c | 13 ++---
arch/x86/include/asm/perf_event.h | 12
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 62f317c..5b35b7e 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -661,10 +661,17 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
throttle = perf_event_overflow(event, , );
out:
- if (throttle)
+ if (throttle) {
perf_ibs_stop(event, 0);
- else
- perf_ibs_enable_event(perf_ibs, hwc, period >> 4);
+ } else {
+ period >>= 4;
+
+ if ((ibs_caps & IBS_CAPS_RDWROPCNT) &&
+ (*config & IBS_OP_CNT_CTL))
+ period |= *config & IBS_OP_CUR_CNT_RAND;
+
+ perf_ibs_enable_event(perf_ibs, hwc, period);
+ }
perf_event_update_userpage(event);
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index 1392d5e..ee26e92 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -252,16 +252,20 @@ struct pebs_lbr {
#define IBSCTL_LVT_OFFSET_VALID(1ULL<<8)
#define IBSCTL_LVT_OFFSET_MASK 0x0F
-/* ibs fetch bits/masks */
+/* IBS fetch bits/masks */
#define IBS_FETCH_RAND_EN (1ULL<<57)
#define IBS_FETCH_VAL (1ULL<<49)
#define IBS_FETCH_ENABLE (1ULL<<48)
#define IBS_FETCH_CNT 0xULL
#define IBS_FETCH_MAX_CNT 0xULL
-/* ibs op bits/masks */
-/* lower 4 bits of the current count are ignored: */
-#define IBS_OP_CUR_CNT (0x0ULL<<32)
+/*
+ * IBS op bits/masks
+ * The lower 7 bits of the current count are random bits
+ * preloaded by hardware and ignored in software
+ */
+#define IBS_OP_CUR_CNT (0xFFF80ULL<<32)
+#define IBS_OP_CUR_CNT_RAND(0x0007FULL<<32)
#define IBS_OP_CNT_CTL (1ULL<<19)
#define IBS_OP_VAL (1ULL<<18)
#define IBS_OP_ENABLE (1ULL<<17)
[RFC] perf/x86/amd: add support for Large Increment per Cycle Events
The core AMD PMU has a 4-bit wide per-cycle increment for each
performance monitor counter. That works for most counters, but
now with AMD Family 17h and above processors, for some, more than 15
events can occur in a cycle. Those events are called "Large
Increment per Cycle" events, and one example is the number of
SSE/AVX FLOPs retired (event code 0x003). In order to count these
events, two adjacent h/w PMCs get their count signals merged
to form 8 bits per cycle total. In addition, the PERF_CTR count
registers are merged to be able to count up to 64 bits.
Normally, events like instructions retired, get programmed on a single
counter like so:
PERF_CTL0 (MSR 0xc0010200) 0x0053ff0c # event 0x0c, umask 0xff
PERF_CTR0 (MSR 0xc0010201) 0x8001 # r/w 48-bit count
The next counter at MSRs 0xc0010202-3 remains unused, or can be used
independently to count something else.
When counting Large Increment per Cycle events, such as FLOPs,
however, we now have to reserve the next counter and program the
PERF_CTL (config) register with the Merge event (0xFFF), like so:
PERF_CTL0 (msr 0xc0010200) 0x0053ff03 # FLOPs event, umask 0xff
PERF_CTR0 (msr 0xc0010201) 0x8001 # read 64-bit count, wr low 48b
PERF_CTL1 (msr 0xc0010202) 0x000f004000ff # Merge event, enable bit
PERF_CTR1 (msr 0xc0010203) 0x # write higher 16-bits of count
The count is widened from the normal 48-bits to 64 bits by having the
second counter carry the higher 16 bits of the count in its lower 16
bits of its counter register. Support for mixed 48- and 64-bit counting
is not supported in this version.
For more details, search a Family 17h PPR for the "Large Increment per
Cycle Events" section, e.g., section 2.1.15.3 on p. 173 in this version:
https://www.amd.com/system/files/TechDocs/56176_ppr_Family_17h_Model_71h_B0_pub_Rev_3.06.zip
In order to support reserving the extra counter for a single Large
Increment per Cycle event in the perf core, we:
1. Add a f17h get_event_constraints() that returns only an even counter
bitmask, since Large Increment events can only be placed on counters 0,
2, and 4 out of the currently available 0-5.
2. We add a commit_scheduler hook that adds the Merge event (0xFFF) to
any Large Increment event being scheduled. If the event being scheduled
is not a Large Increment event, we check for, and remove any
pre-existing Large Increment events on the next counter.
3. In the main x86 scheduler, we reduce the number of available
counters by the number of Large Increment per Cycle events being added.
This improves the counter scheduler success rate.
4. In perf_assign_events(), if a counter is assigned to a Large
Increment event, we increment the current counter variable, so the
counter used for the Merge event is skipped.
5. In find_counter(), if a counter has been found for the
Large Increment event, we set the next counter as used, to
prevent other events from using it.
A side-effect of assigning a new get_constraints function for f17h
disables calling the old (prior to f15h) amd_get_event_constraints
implementation left enabled by commit e40ed1542dd7 ("perf/x86: Add perf
support for AMD family-17h processors"), which is no longer
necessary since those North Bridge events are obsolete.
Simple invocation example:
perf stat -e cpu/fp_ret_sse_avx_ops.all/,cpu/instructions/, \
cpu/event=0x03,umask=0xff/
Performance counter stats for '':
800,000,000 cpu/fp_ret_sse_avx_ops.all/u
300,042,101 cpu/instructions/u
800,000,000 cpu/event=0x03,umask=0xff/u
0.041359898 seconds time elapsed
0.04120 seconds user
0.0 seconds sys
Fixes: e40ed1542dd7 ("perf/x86: Add perf support for AMD family-17h processors")
Signed-off-by: Kim Phillips
Cc: Janakarajan Natarajan
Cc: Suravee Suthikulpanit
Cc: Tom Lendacky
Cc: Stephane Eranian
Cc: Martin Liska
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
---
RFC because I'd like input on the approach, including how to add support
for mixed-width (48- and 64-bit) counting for a single PMU. Plus there
are bugs:
- with nmi_watchdog=0, single invocations work, but it fails to count
correctly under when invoking two simultaneous perfs pinned to the
same cpu
- it fails to count correctly under certain conditions with
nmi_watchdog=1
arch/x86/events/amd/core.c | 102 +++
arch/x86/events/core.c | 39 +-
arch/x86/events/perf_event.h | 46
3 files changed, 163 insertions(+), 24 deletions(-)
diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index e7d35f60d53f..351e72449fb8 100644
--- a/arch/x86/events/amd/core.
[PATCH] perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops
When counting dispatched micro-ops with cnt_ctl=1, in order to prevent
sample bias, IBS hardware preloads the least significant 7 bits of
current count (IbsOpCurCnt) with random values, such that, after the
interrupt is handled and counting resumes, the next sample taken
will be slightly perturbed.
The current count bitfield is in the IBS execution control h/w register,
alongside the maximum count field.
Currently, the IBS driver writes that register with the maximum count,
leaving zeroes to fill the current count field, thereby overwriting
the random bits the hardware preloaded for itself.
Fix the driver to actually retain and carry those random bits from the
read of the IBS control register, through to its write, instead of
overwriting the lower current count bits with zeroes.
Tested with:
perf record -c 11 -e ibs_op/cnt_ctl=1/pp -a -C 0 taskset -c 0
'perf annotate' output before:
15.70 65: addsd %xmm0,%xmm1
17.30add $0x1,%rax
15.88cmp %rdx,%rax
je82
17.32 72: test $0x1,%al
jne 7c
7.52movapd%xmm1,%xmm0
5.90jmp 65
8.23 7c: sqrtsd%xmm1,%xmm0
12.15jmp 65
'perf annotate' output after:
16.63 65: addsd %xmm0,%xmm1
16.82add $0x1,%rax
16.81cmp %rdx,%rax
je82
16.69 72: test $0x1,%al
jne 7c
8.30movapd%xmm1,%xmm0
8.13jmp 65
8.24 7c: sqrtsd%xmm1,%xmm0
8.39jmp 65
Tested on Family 15h and 17h machines.
Machines prior to family 10h Rev. C don't have the RDWROPCNT capability,
and have the IbsOpCurCnt bitfield reserved, so this patch shouldn't
affect their operation.
It is unknown why commit db98c5faf8cb ("perf/x86: Implement 64-bit
counter support for IBS") ignored the lower 4 bits of the IbsOpCurCnt
field; the number of preloaded random bits has always been 7, AFAICT.
Signed-off-by: Kim Phillips
Cc: Stephane Eranian
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
---
arch/x86/events/amd/ibs.c | 11 +--
arch/x86/include/asm/perf_event.h | 9 ++---
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 62f317c9113a..f2625b4a5a8b 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -663,8 +663,15 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs,
struct pt_regs *iregs)
out:
if (throttle)
perf_ibs_stop(event, 0);
- else
- perf_ibs_enable_event(perf_ibs, hwc, period >> 4);
+ else {
+ period >>= 4;
+
+ if ((ibs_caps & IBS_CAPS_RDWROPCNT) &&
+ (*config & IBS_OP_CNT_CTL))
+ period |= *config & IBS_OP_CUR_CNT_RAND;
+
+ perf_ibs_enable_event(perf_ibs, hwc, period);
+ }
perf_event_update_userpage(event);
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index 1392d5e6e8d6..67d94696a1d6 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -259,9 +259,12 @@ struct pebs_lbr {
#define IBS_FETCH_CNT 0xULL
#define IBS_FETCH_MAX_CNT 0xULL
-/* ibs op bits/masks */
-/* lower 4 bits of the current count are ignored: */
-#define IBS_OP_CUR_CNT (0x0ULL<<32)
+/* ibs op bits/masks
+ * The lower 7 bits of the current count are random bits
+ * preloaded by hardware and ignored in software
+ */
+#define IBS_OP_CUR_CNT (0xFFF80ULL<<32)
+#define IBS_OP_CUR_CNT_RAND(0x0007FULL<<32)
#define IBS_OP_CNT_CTL (1ULL<<19)
#define IBS_OP_VAL (1ULL<<18)
#define IBS_OP_ENABLE (1ULL<<17)
--
2.23.0
[tip:perf/urgent] perf/x86/amd/uncore: Do not set 'ThreadMask' and 'SliceMask' for non-L3 PMCs
Commit-ID: 16f4641166b10e199f0d7b68c2c5f004fef0bda3
Gitweb: https://git.kernel.org/tip/16f4641166b10e199f0d7b68c2c5f004fef0bda3
Author: Kim Phillips
AuthorDate: Fri, 28 Jun 2019 21:59:20 +
Committer: Ingo Molnar
CommitDate: Sat, 13 Jul 2019 11:21:26 +0200
perf/x86/amd/uncore: Do not set 'ThreadMask' and 'SliceMask' for non-L3 PMCs
The following commit:
d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache
perf events")
enables L3 PMC events for all threads and slices by writing 1's in
'ChL3PmcCfg' (L3 PMC PERF_CTL) register fields.
Those bitfields overlap with high order event select bits in the Data
Fabric PMC control register, however.
So when a user requests raw Data Fabric events (-e amd_df/event=0xYYY/),
the two highest order bits get inadvertently set, changing the counter
select to events that don't exist, and for which no counts are read.
This patch changes the logic to write the L3 masks only when dealing
with L3 PMC counters.
AMD Family 16h and below Northbridge (NB) counters were not affected.
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc:
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Gary Hook
Cc: H. Peter Anvin
Cc: Janakarajan Natarajan
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Martin Liska
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Pu Wen
Cc: Stephane Eranian
Cc: Suravee Suthikulpanit
Cc: Thomas Gleixner
Cc: Vince Weaver
Fixes: d7cbbe49a930 ("perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3
Cache perf events")
Link: https://lkml.kernel.org/r/20190628215906.4276-1-kim.phill...@amd.com
Signed-off-by: Ingo Molnar
---
arch/x86/events/amd/uncore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 85e6984c560b..c2c4ae5fbbfc 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -206,7 +206,7 @@ static int amd_uncore_event_init(struct perf_event *event)
* SliceMask and ThreadMask need to be set for certain L3 events in
* Family 17h. For other events, the two fields do not affect the count.
*/
- if (l3_mask)
+ if (l3_mask && is_llc_event(event))
hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
if (event->cpu < 0)
[tip:perf/urgent] perf/x86/amd/uncore: Set the thread mask for F17h L3 PMCs
Commit-ID: 2f217d58a8a086d3399fecce39fb358848e799c4
Gitweb: https://git.kernel.org/tip/2f217d58a8a086d3399fecce39fb358848e799c4
Author: Kim Phillips
AuthorDate: Fri, 28 Jun 2019 21:59:33 +
Committer: Ingo Molnar
CommitDate: Sat, 13 Jul 2019 11:21:27 +0200
perf/x86/amd/uncore: Set the thread mask for F17h L3 PMCs
Fill in the L3 performance event select register ThreadMask
bitfield, to enable per hardware thread accounting.
Signed-off-by: Kim Phillips
Signed-off-by: Peter Zijlstra (Intel)
Cc:
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Gary Hook
Cc: H. Peter Anvin
Cc: Janakarajan Natarajan
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Martin Liska
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Pu Wen
Cc: Stephane Eranian
Cc: Suravee Suthikulpanit
Cc: Thomas Gleixner
Cc: Vince Weaver
Link: https://lkml.kernel.org/r/20190628215906.4276-2-kim.phill...@amd.com
Signed-off-by: Ingo Molnar
---
arch/x86/events/amd/uncore.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index c2c4ae5fbbfc..a6ea07f2aa84 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -202,15 +202,22 @@ static int amd_uncore_event_init(struct perf_event *event)
hwc->config = event->attr.config & AMD64_RAW_EVENT_MASK_NB;
hwc->idx = -1;
+ if (event->cpu < 0)
+ return -EINVAL;
+
/*
* SliceMask and ThreadMask need to be set for certain L3 events in
* Family 17h. For other events, the two fields do not affect the count.
*/
- if (l3_mask && is_llc_event(event))
- hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK);
+ if (l3_mask && is_llc_event(event)) {
+ int thread = 2 * (cpu_data(event->cpu).cpu_core_id % 4);
- if (event->cpu < 0)
- return -EINVAL;
+ if (smp_num_siblings > 1)
+ thread += cpu_data(event->cpu).apicid & 1;
+
+ hwc->config |= (1ULL << (AMD64_L3_THREAD_SHIFT + thread) &
+ AMD64_L3_THREAD_MASK) | AMD64_L3_SLICE_MASK;
+ }
uncore = event_to_amd_uncore(event);
if (!uncore)
Re: [PATCH v3 1/6] EDAC/amd64: Add Family 17h Model 30h PCI IDs
Hi Boris,
I've tested this patch and it gets rid of a slew of these messages:
kernel: EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?)
kernel: EDAC amd64: Error: Error probing instance: 0
So please add my:
Tested-by: Kim Phillips
Thank you,
Kim
On 3/21/19 3:30 PM, Ghannam, Yazen wrote:
> Hi Boris,
>
> Any comments on this set?
>
> Thanks,
> Yazen
>
>> -Original Message-
>> From: linux-edac-ow...@vger.kernel.org On
>> Behalf Of Ghannam, Yazen
>> Sent: Thursday, February 28, 2019 9:36 AM
>> To: linux-e...@vger.kernel.org
>> Cc: Ghannam, Yazen ; linux-kernel@vger.kernel.org;
>> b...@alien8.de
>> Subject: [PATCH v3 1/6] EDAC/amd64: Add Family 17h Model 30h PCI IDs
>>
>> From: Yazen Ghannam
>>
>> Add the new Family 17h Model 30h PCI IDs to the AMD64 EDAC module.
>>
>> This also fixes a probe failure that appeared when some other PCI IDs
>> for Family 17h Model 30h were added to the AMD NB code.
>>
>> Fixes: be3518a16ef2 (x86/amd_nb: Add PCI device IDs for family 17h, model
>> 30h)
>> Signed-off-by: Yazen Ghannam
>> ---
>> Link:
>> https://lkml.kernel.org/r/20190226172532.12924-1-yazen.ghan...@amd.com
>>
>> v2->v3:
>> * No change.
>>
>> v1->v2:
>> * Write out "Family" and "Model" in commit message.
>> * Sort model checks in increasing order.
>>
>> drivers/edac/amd64_edac.c | 13 +
>> drivers/edac/amd64_edac.h | 3 +++
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>> index 6ea98575a402..98e8da9d9f5b 100644
>> --- a/drivers/edac/amd64_edac.c
>> +++ b/drivers/edac/amd64_edac.c
>> @@ -2211,6 +2211,15 @@ static struct amd64_family_type family_types[] = {
>> .dbam_to_cs = f17_base_addr_to_cs_size,
>> }
>> },
>> +[F17_M30H_CPUS] = {
>> +.ctl_name = "F17h_M30h",
>> +.f0_id = PCI_DEVICE_ID_AMD_17H_M30H_DF_F0,
>> +.f6_id = PCI_DEVICE_ID_AMD_17H_M30H_DF_F6,
>> +.ops = {
>> +.early_channel_count= f17_early_channel_count,
>> +.dbam_to_cs = f17_base_addr_to_cs_size,
>> +}
>> +},
>> };
>>
>> /*
>> @@ -3203,6 +3212,10 @@ static struct amd64_family_type
>> *per_family_init(struct amd64_pvt *pvt)
>> fam_type = _types[F17_M10H_CPUS];
>> pvt->ops = _types[F17_M10H_CPUS].ops;
>> break;
>> +} else if (pvt->model >= 0x30 && pvt->model <= 0x3f) {
>> +fam_type = _types[F17_M30H_CPUS];
>> +pvt->ops = _types[F17_M30H_CPUS].ops;
>> +break;
>> }
>> /* fall through */
>> case 0x18:
>> diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
>> index 4242f8e39c18..de8dbb0b42b5 100644
>> --- a/drivers/edac/amd64_edac.h
>> +++ b/drivers/edac/amd64_edac.h
>> @@ -117,6 +117,8 @@
>> #define PCI_DEVICE_ID_AMD_17H_DF_F6 0x1466
>> #define PCI_DEVICE_ID_AMD_17H_M10H_DF_F0 0x15e8
>> #define PCI_DEVICE_ID_AMD_17H_M10H_DF_F6 0x15ee
>> +#define PCI_DEVICE_ID_AMD_17H_M30H_DF_F0 0x1490
>> +#define PCI_DEVICE_ID_AMD_17H_M30H_DF_F6 0x1496
>>
>> /*
>> * Function 1 - Address Map
>> @@ -284,6 +286,7 @@ enum amd_families {
>> F16_M30H_CPUS,
>> F17_CPUS,
>> F17_M10H_CPUS,
>> +F17_M30H_CPUS,
>> NUM_FAMILIES,
>> };
>>
>> --
>> 2.17.1
>
>
Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
On 1/17/19 2:13 AM, Benjamin Tissoires wrote: On Wed, Jan 16, 2019 at 5:59 AM Kim Phillips wrote: On 1/15/19 2:57 AM, Benjamin Tissoires wrote: On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov wrote: On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote: On 1/11/19 7:40 PM, Dmitry Torokhov wrote: Hi Kim, Hi Dmitry, On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote: This patch is the result of seeing this message: psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-in...@vger.kernel.org. If I set psmouse.synaptics_intertouch=1, or add the PNP ID to smbus_pnp_ids, the touchpad continues to work, and the above message goes away, but we now get: psmouse serio1: synaptics: Trying to set up SMBus access psmouse serio1: synaptics: SMbus companion is not ready yet With this patch applied, i.e., the PNP IDs are added to the forcepad array, the touchpad continues to work and all of the above messages disappear. Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have physical button underneath it)? As far as I know there were only couple of HP laptops with forcepads and when switching to RMI mode forcepads need F21 handler that we do not currently have in the kernel. I see, no, I'm not sure, but assuming you're right, the IDs should be added to the smbus array instead, after fixing the SMbus "companion not ready" problem? Pointers for that and the below interrupts when touchpad idle after resume, welcome. Also, the link to get the RMI4 spec in Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt is broken. Any pointers for that also appreciated. OK, sorting it all out some more: - because we do not have support for F21 necessary for forcepads adding APIC ID to forcepad list actuallty disables SMbus companion mode, that is why you no longer see "companion not ready" messages vs. setting psmouse.synaptics_intertouch=1 module parameter. Yep - this does not really matter as your touchpad ends up being driven by i2c-hid and hid-multitouch drivers, and that is how we wait it to work, as we do not want to deviate from behavior on Windows since OEM tested it (the device and firmware) in tha configuration. Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus wired at all, so we can't enable SMBus for them. Also, the fact that the device gets loaded over i2c-hid means that we can't know that it is the case from the psmouse/synaptics point of view. Sigh, OK, I wasn't registering the word "not" when reading "If i2c-hid and hid-rmi are not used" too quickly. - we need to figure out issue with interrupts on resume, maybe Benjamin have seen it? First time I see it. I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem. I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is also keeping firing the interrupts, but not the touchpad. However, here, the interrupts are not stopping when I touch the touchscreen or if I approach a pen. Kim, rmmod-ing i2c-hid and modprobing back it with the parameter debug=1 doesn't show any events processed when the interrupts are firing. Do you see the same? After rmmodding i2c_hid, the WCOM488F and SYNA2393 entries in /proc/interrupts somewhat expectedly disappear, however, the modprobe (with or without debug=1) fails to bring them back, with these messages left in dmesg: [ 3882.073222] calling i2c_hid_driver_init+0x0/0x1000 [i2c_hid] @ 3082 [ 3882.180938] i2c_hid i2c-WCOM488F:00: HID over i2c has not been provided an Int IRQ [ 3882.181060] i2c_hid: probe of i2c-WCOM488F:00 failed with error -22 [ 3882.181065] probe of i2c-WCOM488F:00 returned 0 after 496 usecs [ 3882.289196] i2c_hid i2c-SYNA2393:00: HID over i2c has not been provided an Int IRQ [ 3882.289318] i2c_hid: probe of i2c-SYNA2393:00 failed with error -22 [ 3882.289321] probe of i2c-SYNA2393:00 returned 0 after 508 usecs [ 3882.289418] initcall i2c_hid_driver_init+0x0/0x1000 [i2c_hid] returned 0 after 29 usecs Yes, that is a weird behavior I experience the other day also. It looks like rmmod-ing the driver simply kills the irq description attached to the i2c node. This waasn't the case previously, and I wonder if the issue is in i2c-hid (unlikely) or in i2c-core. In order to work around that problem, I set h2c_hid.debug=1 in the boot command line, and after a resume, dmesg contains these messages, relevant to i2c_hid: [ 267.235673] i2c_hid i2c-WCOM488F:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3078, parent: i2c-9 [ 267.235676] input input16: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0 [ 267.235681] input input16: input_dev_resume+0x0/0x50 returned 0 after 0 usecs [ 267.235682] i2c_hid i2c-WCOM488F:00: i2c_hid_set_pow
Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
On 1/15/19 2:57 AM, Benjamin Tissoires wrote: On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov wrote: On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote: On 1/11/19 7:40 PM, Dmitry Torokhov wrote: Hi Kim, Hi Dmitry, On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote: This patch is the result of seeing this message: psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-in...@vger.kernel.org. If I set psmouse.synaptics_intertouch=1, or add the PNP ID to smbus_pnp_ids, the touchpad continues to work, and the above message goes away, but we now get: psmouse serio1: synaptics: Trying to set up SMBus access psmouse serio1: synaptics: SMbus companion is not ready yet With this patch applied, i.e., the PNP IDs are added to the forcepad array, the touchpad continues to work and all of the above messages disappear. Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have physical button underneath it)? As far as I know there were only couple of HP laptops with forcepads and when switching to RMI mode forcepads need F21 handler that we do not currently have in the kernel. I see, no, I'm not sure, but assuming you're right, the IDs should be added to the smbus array instead, after fixing the SMbus "companion not ready" problem? Pointers for that and the below interrupts when touchpad idle after resume, welcome. Also, the link to get the RMI4 spec in Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt is broken. Any pointers for that also appreciated. OK, sorting it all out some more: - because we do not have support for F21 necessary for forcepads adding APIC ID to forcepad list actuallty disables SMbus companion mode, that is why you no longer see "companion not ready" messages vs. setting psmouse.synaptics_intertouch=1 module parameter. Yep - this does not really matter as your touchpad ends up being driven by i2c-hid and hid-multitouch drivers, and that is how we wait it to work, as we do not want to deviate from behavior on Windows since OEM tested it (the device and firmware) in tha configuration. Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus wired at all, so we can't enable SMBus for them. Also, the fact that the device gets loaded over i2c-hid means that we can't know that it is the case from the psmouse/synaptics point of view. Sigh, OK, I wasn't registering the word "not" when reading "If i2c-hid and hid-rmi are not used" too quickly. - we need to figure out issue with interrupts on resume, maybe Benjamin have seen it? First time I see it. I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem. I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is also keeping firing the interrupts, but not the touchpad. However, here, the interrupts are not stopping when I touch the touchscreen or if I approach a pen. Kim, rmmod-ing i2c-hid and modprobing back it with the parameter debug=1 doesn't show any events processed when the interrupts are firing. Do you see the same? After rmmodding i2c_hid, the WCOM488F and SYNA2393 entries in /proc/interrupts somewhat expectedly disappear, however, the modprobe (with or without debug=1) fails to bring them back, with these messages left in dmesg: [ 3882.073222] calling i2c_hid_driver_init+0x0/0x1000 [i2c_hid] @ 3082 [ 3882.180938] i2c_hid i2c-WCOM488F:00: HID over i2c has not been provided an Int IRQ [ 3882.181060] i2c_hid: probe of i2c-WCOM488F:00 failed with error -22 [ 3882.181065] probe of i2c-WCOM488F:00 returned 0 after 496 usecs [ 3882.289196] i2c_hid i2c-SYNA2393:00: HID over i2c has not been provided an Int IRQ [ 3882.289318] i2c_hid: probe of i2c-SYNA2393:00 failed with error -22 [ 3882.289321] probe of i2c-SYNA2393:00 returned 0 after 508 usecs [ 3882.289418] initcall i2c_hid_driver_init+0x0/0x1000 [i2c_hid] returned 0 after 29 usecs In order to work around that problem, I set h2c_hid.debug=1 in the boot command line, and after a resume, dmesg contains these messages, relevant to i2c_hid: [ 267.235673] i2c_hid i2c-WCOM488F:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3078, parent: i2c-9 [ 267.235676] input input16: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0 [ 267.235681] input input16: input_dev_resume+0x0/0x50 returned 0 after 0 usecs [ 267.235682] i2c_hid i2c-WCOM488F:00: i2c_hid_set_power [ 267.235687] input input17: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0 [ 267.235689] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 00 08 [ 267.235693] input input17: input_dev_resume+0x0/0x50 returned 0 after 0 usecs [ 267.235698] idma64 idma64.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: :00:15.1 [ 267.235701] idma64 idma64.1
Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
On 1/11/19 7:40 PM, Dmitry Torokhov wrote: > Hi Kim, Hi Dmitry, > On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote: >> This patch is the result of seeing this message: >> >> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can >> support a different bus. If i2c-hid and hid-rmi are not used, you might want >> to try setting psmouse.synaptics_intertouch to 1 and report this to >> linux-in...@vger.kernel.org. >> >> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to >> smbus_pnp_ids, the touchpad continues to work, and the above message >> goes away, but we now get: >> >> psmouse serio1: synaptics: Trying to set up SMBus access >> psmouse serio1: synaptics: SMbus companion is not ready yet >> >> With this patch applied, i.e., the PNP IDs are added to the forcepad >> array, the touchpad continues to work and all of the above messages >> disappear. > > Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have > physical button underneath it)? As far as I know there were only couple > of HP laptops with forcepads and when switching to RMI mode forcepads > need F21 handler that we do not currently have in the kernel. I see, no, I'm not sure, but assuming you're right, the IDs should be added to the smbus array instead, after fixing the SMbus "companion not ready" problem? Pointers for that and the below interrupts when touchpad idle after resume, welcome. Also, the link to get the RMI4 spec in Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt is broken. Any pointers for that also appreciated. >> --- >> With or without this patch, I'm seeing a problem where when the XPS 15 >> comes out of a resume, and without even touching the touchpad, I notice >> about 600 interrupts per second firing on the "IR-IO-APIC 51-fasteoi >> SYNA2393:00" line in /proc/interrupts. If I start using the touchpad, >> then leave it alone, I check if there are still interrupts firing, and >> they have indeed stopped. This adversely affects my battery life when >> using an external mouse. Any ideas on how to debug the situation? >> Could it be related to the 'vdd not found' messages?: >> >> $ dmesg | grep -C 1 -i syna >> probe of 1-12 returned 1 after 2343 usecs >> psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646] >> psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..] >> psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: >> 0xf00123/0x840300/0x12e800/0x0, board id: 3125, fw id: 2378871 >> input: SynPS/2 Synaptics TouchPad as >> /devices/platform/i8042/serio1/input/input6 >> probe of serio1 returned 1 after 939332 usecs >> -- >> probe of idma64.1 returned 1 after 72 usecs >> i2c_hid i2c-SYNA2393:00: i2c-SYNA2393:00 supply vdd not found, using dummy >> regulator >> i2c_hid i2c-SYNA2393:00: Linked as a consumer to regulator.0 >> i2c_hid i2c-SYNA2393:00: i2c-SYNA2393:00 supply vddl not found, using dummy >> regulator >> ath10k_pci :3b:00.0: qca6174 hw3.2 target 0x0503 chip_id 0x00340aff >> sub 1a56:1535 >> -- >> ath10k_pci :3b:00.0: firmware ver WLAN.RM.4.4.1-00079-QCARMSWPZ-1 api 6 >> features wowlan,ignore-otp crc32 fd869beb >> probe of i2c-SYNA2393:00 returned 1 after 23978 usecs >> ath10k_pci :3b:00.0: board_file api 2 bmi_id N/A crc32 20d869c3 >> -- >> probe of 0018:056A:488F.0001 returned 1 after 1366 usecs >> input: SYNA2393:00 06CB:7A13 Mouse as >> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input23 >> input: SYNA2393:00 06CB:7A13 Touchpad as >> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input24 >> hid-generic 0018:06CB:7A13.0002: input,hidraw1: I2C HID v1.00 Mouse >> [SYNA2393:00 06CB:7A13] on i2c-SYNA2393:00 >> probe of 0018:06CB:7A13.0002 returned 1 after 320 usecs >> -- >> probe of 0018:06CB:7A13.0002 returned 0 after 5 usecs >> input: SYNA2393:00 06CB:7A13 Touchpad as >> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input27 >> hid-multitouch 0018:06CB:7A13.0002: input,hidraw1: I2C HID v1.00 Mouse >> [SYNA2393:00 06CB:7A13] on i2c-SYNA2393:00 >> probe of 0018:06CB:7A13.0002 returned 1 after 25104 usecs Thanks, Kim
[PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
This patch is the result of seeing this message:
psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can
support a different bus. If i2c-hid and hid-rmi are not used, you might want to
try setting psmouse.synaptics_intertouch to 1 and report this to
linux-in...@vger.kernel.org.
If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
smbus_pnp_ids, the touchpad continues to work, and the above message
goes away, but we now get:
psmouse serio1: synaptics: Trying to set up SMBus access
psmouse serio1: synaptics: SMbus companion is not ready yet
With this patch applied, i.e., the PNP IDs are added to the forcepad
array, the touchpad continues to work and all of the above messages
disappear.
Tested on a Dell XPS 15 9570. The other IDs - for Dell XPS 13
9350/9360/9370 and XPS 15 9550/9560 - were obtained by searching
for the model numbers and "says it can support a different bus".
E.g, this is one such instance:
https://lkml.org/lkml/2018/2/15/52
Cc: Paul Menzel
Cc: Dmitry Torokhov
Cc: Benjamin Tissoires
Cc: linux-in...@vger.kernel.org
Signed-off-by: Kim Phillips
---
With or without this patch, I'm seeing a problem where when the XPS 15
comes out of a resume, and without even touching the touchpad, I notice
about 600 interrupts per second firing on the "IR-IO-APIC 51-fasteoi
SYNA2393:00" line in /proc/interrupts. If I start using the touchpad,
then leave it alone, I check if there are still interrupts firing, and
they have indeed stopped. This adversely affects my battery life when
using an external mouse. Any ideas on how to debug the situation?
Could it be related to the 'vdd not found' messages?:
$ dmesg | grep -C 1 -i syna
probe of 1-12 returned 1 after 2343 usecs
psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]
psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..]
psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps:
0xf00123/0x840300/0x12e800/0x0, board id: 3125, fw id: 2378871
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input6
probe of serio1 returned 1 after 939332 usecs
--
probe of idma64.1 returned 1 after 72 usecs
i2c_hid i2c-SYNA2393:00: i2c-SYNA2393:00 supply vdd not found, using dummy
regulator
i2c_hid i2c-SYNA2393:00: Linked as a consumer to regulator.0
i2c_hid i2c-SYNA2393:00: i2c-SYNA2393:00 supply vddl not found, using dummy
regulator
ath10k_pci :3b:00.0: qca6174 hw3.2 target 0x0503 chip_id 0x00340aff sub
1a56:1535
--
ath10k_pci :3b:00.0: firmware ver WLAN.RM.4.4.1-00079-QCARMSWPZ-1 api 6
features wowlan,ignore-otp crc32 fd869beb
probe of i2c-SYNA2393:00 returned 1 after 23978 usecs
ath10k_pci :3b:00.0: board_file api 2 bmi_id N/A crc32 20d869c3
--
probe of 0018:056A:488F.0001 returned 1 after 1366 usecs
input: SYNA2393:00 06CB:7A13 Mouse as
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input23
input: SYNA2393:00 06CB:7A13 Touchpad as
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input24
hid-generic 0018:06CB:7A13.0002: input,hidraw1: I2C HID v1.00 Mouse
[SYNA2393:00 06CB:7A13] on i2c-SYNA2393:00
probe of 0018:06CB:7A13.0002 returned 1 after 320 usecs
--
probe of 0018:06CB:7A13.0002 returned 0 after 5 usecs
input: SYNA2393:00 06CB:7A13 Touchpad as
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input27
hid-multitouch 0018:06CB:7A13.0002: input,hidraw1: I2C HID v1.00 Mouse
[SYNA2393:00 06CB:7A13] on i2c-SYNA2393:00
probe of 0018:06CB:7A13.0002 returned 1 after 25104 usecs
drivers/input/mouse/synaptics.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index b6da0c1267e3..e3fb4b9346c0 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -185,6 +185,12 @@ static const char * const smbus_pnp_ids[] = {
};
static const char * const forcepad_pnp_ids[] = {
+ "DLL06e4", /* Dell XPS 15 9550 */
+ "DLL0704", /* Dell XPS 13 9350 */
+ "DLL075b", /* Dell XPS 13 9360 */
+ "DLL07be", /* Dell XPS 15 9560 */
+ "DLL07e6", /* Dell XPS 13 9370 */
+ "DLL087c", /* Dell XPS 15 9570 */
"SYN300D",
"SYN3014",
NULL
--
2.20.1
[tip:perf/core] perf annotate: Handle arm64 move instructions
Commit-ID: 58094c48f4079cfc784f53a73caaa446db436389
Gitweb: https://git.kernel.org/tip/58094c48f4079cfc784f53a73caaa446db436389
Author: Kim Phillips
AuthorDate: Mon, 27 Aug 2018 15:08:07 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 30 Aug 2018 15:52:25 -0300
perf annotate: Handle arm64 move instructions
Add default handler for non-jump instructions. This really only has an
effect on instructions that compute a PC-relative address, such as
'adrp,' as seen in these couple of examples:
BEFORE: adrp x0, 2aa11000
AFTER: adrp x0, kallsyms_token_index+0xce000
BEFORE: adrp x23, 2ae94000 <__per_cpu_load>
AFTER: adrp x23, __per_cpu_load
The implementation is identical to that of s390, but with a slight
adjustment for objdump whitespace propagation (arm64 objdump puts spaces
after commas, whereas s390's presumably doesn't).
The mov__scnprintf() declaration is moved from s390's to arm64's
instructions.c because arm64's gets included before s390's.
Committer testing:
Ran 'perf annotate --stdio2 > /tmp/{before,after}' no diff.
Signed-off-by: Kim Phillips
Tested-by: Arnaldo Carvalho de Melo
Tested-by: Thomas Richter
Cc: Alexander Shishkin
Cc: Greg Kroah-Hartman
Cc: Hendrik Brueckner
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20180827150807.304110d2e9919a17c832c...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/arm64/annotate/instructions.c | 59 ++-
tools/perf/arch/s390/annotate/instructions.c | 2 -
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/arm64/annotate/instructions.c
b/tools/perf/arch/arm64/annotate/instructions.c
index 6688977e4ac7..76c6345a57d5 100644
--- a/tools/perf/arch/arm64/annotate/instructions.c
+++ b/tools/perf/arch/arm64/annotate/instructions.c
@@ -8,6 +8,63 @@ struct arm64_annotate {
jump_insn;
};
+static int arm64_mov__parse(struct arch *arch __maybe_unused,
+ struct ins_operands *ops,
+ struct map_symbol *ms __maybe_unused)
+{
+ char *s = strchr(ops->raw, ','), *target, *endptr;
+
+ if (s == NULL)
+ return -1;
+
+ *s = '\0';
+ ops->source.raw = strdup(ops->raw);
+ *s = ',';
+
+ if (ops->source.raw == NULL)
+ return -1;
+
+ target = ++s;
+ ops->target.raw = strdup(target);
+ if (ops->target.raw == NULL)
+ goto out_free_source;
+
+ ops->target.addr = strtoull(target, , 16);
+ if (endptr == target)
+ goto out_free_target;
+
+ s = strchr(endptr, '<');
+ if (s == NULL)
+ goto out_free_target;
+ endptr = strchr(s + 1, '>');
+ if (endptr == NULL)
+ goto out_free_target;
+
+ *endptr = '\0';
+ *s = ' ';
+ ops->target.name = strdup(s);
+ *s = '<';
+ *endptr = '>';
+ if (ops->target.name == NULL)
+ goto out_free_target;
+
+ return 0;
+
+out_free_target:
+ zfree(>target.raw);
+out_free_source:
+ zfree(>source.raw);
+ return -1;
+}
+
+static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
+ struct ins_operands *ops);
+
+static struct ins_ops arm64_mov_ops = {
+ .parse = arm64_mov__parse,
+ .scnprintf = mov__scnprintf,
+};
+
static struct ins_ops *arm64__associate_instruction_ops(struct arch *arch,
const char *name)
{
struct arm64_annotate *arm = arch->priv;
@@ -21,7 +78,7 @@ static struct ins_ops
*arm64__associate_instruction_ops(struct arch *arch, const
else if (!strcmp(name, "ret"))
ops = _ops;
else
- return NULL;
+ ops = _mov_ops;
arch__associate_ins_ops(arch, name, ops);
return ops;
diff --git a/tools/perf/arch/s390/annotate/instructions.c
b/tools/perf/arch/s390/annotate/instructions.c
index cee4e2f7c057..de0dd66dbb48 100644
--- a/tools/perf/arch/s390/annotate/instructions.c
+++ b/tools/perf/arch/s390/annotate/instructions.c
@@ -100,8 +100,6 @@ out_free_source:
return -1;
}
-static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
- struct ins_operands *ops);
static struct ins_ops s390_mov_ops = {
.parse = s390_mov__parse,
[tip:perf/core] perf annotate: Handle arm64 move instructions
Commit-ID: 58094c48f4079cfc784f53a73caaa446db436389
Gitweb: https://git.kernel.org/tip/58094c48f4079cfc784f53a73caaa446db436389
Author: Kim Phillips
AuthorDate: Mon, 27 Aug 2018 15:08:07 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 30 Aug 2018 15:52:25 -0300
perf annotate: Handle arm64 move instructions
Add default handler for non-jump instructions. This really only has an
effect on instructions that compute a PC-relative address, such as
'adrp,' as seen in these couple of examples:
BEFORE: adrp x0, 2aa11000
AFTER: adrp x0, kallsyms_token_index+0xce000
BEFORE: adrp x23, 2ae94000 <__per_cpu_load>
AFTER: adrp x23, __per_cpu_load
The implementation is identical to that of s390, but with a slight
adjustment for objdump whitespace propagation (arm64 objdump puts spaces
after commas, whereas s390's presumably doesn't).
The mov__scnprintf() declaration is moved from s390's to arm64's
instructions.c because arm64's gets included before s390's.
Committer testing:
Ran 'perf annotate --stdio2 > /tmp/{before,after}' no diff.
Signed-off-by: Kim Phillips
Tested-by: Arnaldo Carvalho de Melo
Tested-by: Thomas Richter
Cc: Alexander Shishkin
Cc: Greg Kroah-Hartman
Cc: Hendrik Brueckner
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20180827150807.304110d2e9919a17c832c...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/arm64/annotate/instructions.c | 59 ++-
tools/perf/arch/s390/annotate/instructions.c | 2 -
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/arm64/annotate/instructions.c
b/tools/perf/arch/arm64/annotate/instructions.c
index 6688977e4ac7..76c6345a57d5 100644
--- a/tools/perf/arch/arm64/annotate/instructions.c
+++ b/tools/perf/arch/arm64/annotate/instructions.c
@@ -8,6 +8,63 @@ struct arm64_annotate {
jump_insn;
};
+static int arm64_mov__parse(struct arch *arch __maybe_unused,
+ struct ins_operands *ops,
+ struct map_symbol *ms __maybe_unused)
+{
+ char *s = strchr(ops->raw, ','), *target, *endptr;
+
+ if (s == NULL)
+ return -1;
+
+ *s = '\0';
+ ops->source.raw = strdup(ops->raw);
+ *s = ',';
+
+ if (ops->source.raw == NULL)
+ return -1;
+
+ target = ++s;
+ ops->target.raw = strdup(target);
+ if (ops->target.raw == NULL)
+ goto out_free_source;
+
+ ops->target.addr = strtoull(target, , 16);
+ if (endptr == target)
+ goto out_free_target;
+
+ s = strchr(endptr, '<');
+ if (s == NULL)
+ goto out_free_target;
+ endptr = strchr(s + 1, '>');
+ if (endptr == NULL)
+ goto out_free_target;
+
+ *endptr = '\0';
+ *s = ' ';
+ ops->target.name = strdup(s);
+ *s = '<';
+ *endptr = '>';
+ if (ops->target.name == NULL)
+ goto out_free_target;
+
+ return 0;
+
+out_free_target:
+ zfree(>target.raw);
+out_free_source:
+ zfree(>source.raw);
+ return -1;
+}
+
+static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
+ struct ins_operands *ops);
+
+static struct ins_ops arm64_mov_ops = {
+ .parse = arm64_mov__parse,
+ .scnprintf = mov__scnprintf,
+};
+
static struct ins_ops *arm64__associate_instruction_ops(struct arch *arch,
const char *name)
{
struct arm64_annotate *arm = arch->priv;
@@ -21,7 +78,7 @@ static struct ins_ops
*arm64__associate_instruction_ops(struct arch *arch, const
else if (!strcmp(name, "ret"))
ops = _ops;
else
- return NULL;
+ ops = _mov_ops;
arch__associate_ins_ops(arch, name, ops);
return ops;
diff --git a/tools/perf/arch/s390/annotate/instructions.c
b/tools/perf/arch/s390/annotate/instructions.c
index cee4e2f7c057..de0dd66dbb48 100644
--- a/tools/perf/arch/s390/annotate/instructions.c
+++ b/tools/perf/arch/s390/annotate/instructions.c
@@ -100,8 +100,6 @@ out_free_source:
return -1;
}
-static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
- struct ins_operands *ops);
static struct ins_ops s390_mov_ops = {
.parse = s390_mov__parse,
[tip:perf/core] perf annotate: Fix parsing aarch64 branch instructions after objdump update
Commit-ID: 4e67b2a5df5d3f341776d12ee575e00ca3ef92de
Gitweb: https://git.kernel.org/tip/4e67b2a5df5d3f341776d12ee575e00ca3ef92de
Author: Kim Phillips
AuthorDate: Mon, 27 Aug 2018 12:53:40 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 30 Aug 2018 15:51:54 -0300
perf annotate: Fix parsing aarch64 branch instructions after objdump update
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code
[1].
It is assumed that commas in objdump comments could occur in other
arches now or in the future, so this fix is arch-independent.
The fix could have been done with arm64 specific jump__parse and
jump__scnprintf functions, but the jump__scnprintf instruction would
have to have its comment character be a literal, since the scnprintf
functions cannot receive a struct arch easily.
This inconvenience also applies to the generic jump__scnprintf, which is
why we add a raw_comment pointer to struct ins_operands, so the __parse
function assigns it to be re-used by its corresponding __scnprintf
function.
Example differences in 'perf annotate --stdio2' output on an aarch64
perf.data file:
BEFORE: → b.cs 28133d1c // b.hs, d7ecc47b
AFTER : ↓ b.cs 18c
BEFORE: → b.cc 28d8d9cc // b.lo, b.ul,
d727295b
AFTER : ↓ b.cc 31c
The branch target labels 18c and 31c also now appear in the output:
BEFORE:addx26, x29, #0x80
AFTER : 18c: addx26, x29, #0x80
BEFORE:addx21, x21, #0x8
AFTER : 31c: addx21, x21, #0x8
The Fixes: tag below is added so stable branches will get the update; it
doesn't necessarily mean that commit was broken at the time, rather it
didn't withstand the aarch64 objdump update.
Tested no difference in output for sample x86_64, power arch perf.data files.
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bb7eff5206e4795ac79c177a80fe9f4630aaf730
Signed-off-by: Kim Phillips
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Anton Blanchard
Cc: Christian Borntraeger
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Ravi Bangoria
Cc: Robin Murphy
Cc: Taeung Song
Cc: linux-arm-ker...@lists.infradead.org
Fixes: b13bbeee5ee6 ("perf annotate: Fix branch instruction with multiple
operands")
Link: http://lkml.kernel.org/r/20180827125340.a2f7e291901d17cea05da...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 22 +-
tools/perf/util/annotate.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e62b69ea87cd..28cd6a17491b 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -282,7 +282,19 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops || ins->ops == _call_ops;
}
-static int jump__parse(struct arch *arch __maybe_unused, struct ins_operands
*ops, struct map_symbol *ms)
+/*
+ * Prevents from matching commas in the comment section, e.g.:
+ * 28446e70: b.cs284470f4
// b.hs, b.nlast
+ */
+static inline const char *validate_comma(const char *c, struct ins_operands
*ops)
+{
+ if (ops->raw_comment && c > ops->raw_comment)
+ return NULL;
+
+ return c;
+}
+
+static int jump__parse(struct arch *arch, struct ins_operands *ops, struct
map_symbol *ms)
{
struct map *map = ms->map;
struct symbol *sym = ms->sym;
@@ -291,6 +303,10 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
};
const char *c = strchr(ops->raw, ',');
u64 start, end;
+
+ ops->raw_comment = strchr(ops->raw, arch->objdump.comment_char);
+ c = validate_comma(c, ops);
+
/*
* Examples of lines to parse for the _cpp_lex_token@@Base
* function:
@@ -310,6 +326,7 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
ops->target.addr = strtoull(c, NULL, 16);
if (!ops->target.addr) {
c = strchr(c, ',');
+ c = validate_comma(c, ops);
if (c++ != NULL)
ops->target.addr = strtoull(c, NULL, 16);
}
@@ -367,9 +384,12 @@ static int jump__scnprintf(struct ins *ins, char *bf,
size_t size,
return scnprintf(bf, size, "%-6s %s", ins->name,
ops->target.sym->name);
c = strchr(ops->raw, ',');
+ c = validate_comma(c, ops);
+
if (c != NULL) {
const char *c2 = strchr(c + 1, ',');
+ c2 = validate_comma(c2, ops);
/* check for 3-op insn */
if (c2 != NULL)
c = c2;
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/a
[tip:perf/core] perf annotate: Fix parsing aarch64 branch instructions after objdump update
Commit-ID: 4e67b2a5df5d3f341776d12ee575e00ca3ef92de
Gitweb: https://git.kernel.org/tip/4e67b2a5df5d3f341776d12ee575e00ca3ef92de
Author: Kim Phillips
AuthorDate: Mon, 27 Aug 2018 12:53:40 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 30 Aug 2018 15:51:54 -0300
perf annotate: Fix parsing aarch64 branch instructions after objdump update
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code
[1].
It is assumed that commas in objdump comments could occur in other
arches now or in the future, so this fix is arch-independent.
The fix could have been done with arm64 specific jump__parse and
jump__scnprintf functions, but the jump__scnprintf instruction would
have to have its comment character be a literal, since the scnprintf
functions cannot receive a struct arch easily.
This inconvenience also applies to the generic jump__scnprintf, which is
why we add a raw_comment pointer to struct ins_operands, so the __parse
function assigns it to be re-used by its corresponding __scnprintf
function.
Example differences in 'perf annotate --stdio2' output on an aarch64
perf.data file:
BEFORE: → b.cs 28133d1c // b.hs, d7ecc47b
AFTER : ↓ b.cs 18c
BEFORE: → b.cc 28d8d9cc // b.lo, b.ul,
d727295b
AFTER : ↓ b.cc 31c
The branch target labels 18c and 31c also now appear in the output:
BEFORE:addx26, x29, #0x80
AFTER : 18c: addx26, x29, #0x80
BEFORE:addx21, x21, #0x8
AFTER : 31c: addx21, x21, #0x8
The Fixes: tag below is added so stable branches will get the update; it
doesn't necessarily mean that commit was broken at the time, rather it
didn't withstand the aarch64 objdump update.
Tested no difference in output for sample x86_64, power arch perf.data files.
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bb7eff5206e4795ac79c177a80fe9f4630aaf730
Signed-off-by: Kim Phillips
Tested-by: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Anton Blanchard
Cc: Christian Borntraeger
Cc: Jiri Olsa
Cc: Mark Rutland
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Ravi Bangoria
Cc: Robin Murphy
Cc: Taeung Song
Cc: linux-arm-ker...@lists.infradead.org
Fixes: b13bbeee5ee6 ("perf annotate: Fix branch instruction with multiple
operands")
Link: http://lkml.kernel.org/r/20180827125340.a2f7e291901d17cea05da...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/annotate.c | 22 +-
tools/perf/util/annotate.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e62b69ea87cd..28cd6a17491b 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -282,7 +282,19 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops || ins->ops == _call_ops;
}
-static int jump__parse(struct arch *arch __maybe_unused, struct ins_operands
*ops, struct map_symbol *ms)
+/*
+ * Prevents from matching commas in the comment section, e.g.:
+ * 28446e70: b.cs284470f4
// b.hs, b.nlast
+ */
+static inline const char *validate_comma(const char *c, struct ins_operands
*ops)
+{
+ if (ops->raw_comment && c > ops->raw_comment)
+ return NULL;
+
+ return c;
+}
+
+static int jump__parse(struct arch *arch, struct ins_operands *ops, struct
map_symbol *ms)
{
struct map *map = ms->map;
struct symbol *sym = ms->sym;
@@ -291,6 +303,10 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
};
const char *c = strchr(ops->raw, ',');
u64 start, end;
+
+ ops->raw_comment = strchr(ops->raw, arch->objdump.comment_char);
+ c = validate_comma(c, ops);
+
/*
* Examples of lines to parse for the _cpp_lex_token@@Base
* function:
@@ -310,6 +326,7 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
ops->target.addr = strtoull(c, NULL, 16);
if (!ops->target.addr) {
c = strchr(c, ',');
+ c = validate_comma(c, ops);
if (c++ != NULL)
ops->target.addr = strtoull(c, NULL, 16);
}
@@ -367,9 +384,12 @@ static int jump__scnprintf(struct ins *ins, char *bf,
size_t size,
return scnprintf(bf, size, "%-6s %s", ins->name,
ops->target.sym->name);
c = strchr(ops->raw, ',');
+ c = validate_comma(c, ops);
+
if (c != NULL) {
const char *c2 = strchr(c + 1, ',');
+ c2 = validate_comma(c2, ops);
/* check for 3-op insn */
if (c2 != NULL)
c = c2;
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/a
[tip:perf/core] perf arm64: Fix include path for asm-generic/unistd.h
Commit-ID: 5ab1de932e2923f490645ad017a689c5b58dc433
Gitweb: https://git.kernel.org/tip/5ab1de932e2923f490645ad017a689c5b58dc433
Author: Kim Phillips
AuthorDate: Mon, 6 Aug 2018 17:28:00 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 30 Aug 2018 14:49:24 -0300
perf arm64: Fix include path for asm-generic/unistd.h
The new syscall table support for arm64 mistakenly used the system's
asm-generic/unistd.h file when processing the
tools/arch/arm64/include/uapi/asm/unistd.h file's include directive:
#include
See "Committer notes" section of commit 2b5882435606 "perf arm64:
Generate system call table from asm/unistd.h" for more details.
This patch removes the committer's temporary workaround, and instructs
the host compiler to search the build tree's include path for the right
copy of the unistd.h file, instead of the one on the system's
/usr/include path.
It thus fixes the committer's test that cross-builds an arm64 perf on an
x86 platform running Ubuntu 14.04.5 LTS with an old toolchain:
$ tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
gcc `pwd`/tools tools/arch/arm64/include/uapi/asm/unistd.h | grep bpf
[280] = "bpf",
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Hendrik Brueckner
Cc: Jiri Olsa
Cc: Michael Ellerman
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Ravi Bangoria
Cc: Thomas Richter
Fixes: 2b5882435606 ("perf arm64: Generate system call table from asm/unistd.h")
Link: http://lkml.kernel.org/r/20180806172800.bbcec3cfcc51e2facc978...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/arm64/Makefile| 5 +++--
tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index f013b115dc86..dbef716a1913 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -11,7 +11,8 @@ PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
out:= $(OUTPUT)arch/arm64/include/generated/asm
header := $(out)/syscalls.c
-sysdef := $(srctree)/tools/include/uapi/asm-generic/unistd.h
+incpath := $(srctree)/tools
+sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h
sysprf := $(srctree)/tools/perf/arch/arm64/entry/syscalls/
systbl := $(sysprf)/mksyscalltbl
@@ -19,7 +20,7 @@ systbl := $(sysprf)/mksyscalltbl
_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
$(header): $(sysdef) $(systbl)
- $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(sysdef) > $@
+ $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(incpath) $(sysdef) > $@
clean::
$(call QUIET_CLEAN, arm64) $(RM) $(header)
diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index 52e197317d3e..2dbb8cade048 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -11,7 +11,8 @@
gcc=$1
hostcc=$2
-input=$3
+incpath=$3
+input=$4
if ! test -r $input; then
echo "Could not read input file" >&2
@@ -28,7 +29,6 @@ create_table_from_c()
cat <<-_EoHEADER
#include
- #define __ARCH_WANT_RENAMEAT
#include "$input"
int main(int argc, char *argv[])
{
@@ -42,7 +42,7 @@ create_table_from_c()
printf "%s\n" " printf(\"#define SYSCALLTBL_ARM64_MAX_ID %d\\n\",
__NR_$last_sc);"
printf "}\n"
- } | $hostcc -o $create_table_exe -x c -
+ } | $hostcc -I $incpath/include/uapi -o $create_table_exe -x c -
$create_table_exe
[tip:perf/core] perf arm64: Fix include path for asm-generic/unistd.h
Commit-ID: 5ab1de932e2923f490645ad017a689c5b58dc433
Gitweb: https://git.kernel.org/tip/5ab1de932e2923f490645ad017a689c5b58dc433
Author: Kim Phillips
AuthorDate: Mon, 6 Aug 2018 17:28:00 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 30 Aug 2018 14:49:24 -0300
perf arm64: Fix include path for asm-generic/unistd.h
The new syscall table support for arm64 mistakenly used the system's
asm-generic/unistd.h file when processing the
tools/arch/arm64/include/uapi/asm/unistd.h file's include directive:
#include
See "Committer notes" section of commit 2b5882435606 "perf arm64:
Generate system call table from asm/unistd.h" for more details.
This patch removes the committer's temporary workaround, and instructs
the host compiler to search the build tree's include path for the right
copy of the unistd.h file, instead of the one on the system's
/usr/include path.
It thus fixes the committer's test that cross-builds an arm64 perf on an
x86 platform running Ubuntu 14.04.5 LTS with an old toolchain:
$ tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
gcc `pwd`/tools tools/arch/arm64/include/uapi/asm/unistd.h | grep bpf
[280] = "bpf",
Signed-off-by: Kim Phillips
Cc: Alexander Shishkin
Cc: Hendrik Brueckner
Cc: Jiri Olsa
Cc: Michael Ellerman
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Ravi Bangoria
Cc: Thomas Richter
Fixes: 2b5882435606 ("perf arm64: Generate system call table from asm/unistd.h")
Link: http://lkml.kernel.org/r/20180806172800.bbcec3cfcc51e2facc978...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/arm64/Makefile| 5 +++--
tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index f013b115dc86..dbef716a1913 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -11,7 +11,8 @@ PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
out:= $(OUTPUT)arch/arm64/include/generated/asm
header := $(out)/syscalls.c
-sysdef := $(srctree)/tools/include/uapi/asm-generic/unistd.h
+incpath := $(srctree)/tools
+sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h
sysprf := $(srctree)/tools/perf/arch/arm64/entry/syscalls/
systbl := $(sysprf)/mksyscalltbl
@@ -19,7 +20,7 @@ systbl := $(sysprf)/mksyscalltbl
_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
$(header): $(sysdef) $(systbl)
- $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(sysdef) > $@
+ $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(incpath) $(sysdef) > $@
clean::
$(call QUIET_CLEAN, arm64) $(RM) $(header)
diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index 52e197317d3e..2dbb8cade048 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -11,7 +11,8 @@
gcc=$1
hostcc=$2
-input=$3
+incpath=$3
+input=$4
if ! test -r $input; then
echo "Could not read input file" >&2
@@ -28,7 +29,6 @@ create_table_from_c()
cat <<-_EoHEADER
#include
- #define __ARCH_WANT_RENAMEAT
#include "$input"
int main(int argc, char *argv[])
{
@@ -42,7 +42,7 @@ create_table_from_c()
printf "%s\n" " printf(\"#define SYSCALLTBL_ARM64_MAX_ID %d\\n\",
__NR_$last_sc);"
printf "}\n"
- } | $hostcc -o $create_table_exe -x c -
+ } | $hostcc -I $incpath/include/uapi -o $create_table_exe -x c -
$create_table_exe
Re: [PATCH v4 6/8] perf, tools, script: Make itrace script default to all calls
On Mon, 3 Sep 2018 09:22:47 -0700
Andi Kleen wrote:
> Fix ETM build failure
> ---
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 2ae640257fdb..0296405f38b2 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1432,7 +1432,8 @@ int cs_etm__process_auxtrace_info(union perf_event
> *event,
> if (session->itrace_synth_opts && session->itrace_synth_opts->set) {
> etm->synth_opts = *session->itrace_synth_opts;
> } else {
> - itrace_synth_opts__set_default(>synth_opts);
> + itrace_synth_opts__set_default(>synth_opts,
> + etm->synth_opts->default_no_sample);
This still fails but with a different error:
CC util/cs-etm.o
util/cs-etm.c: In function ‘cs_etm__process_auxtrace_info’:
util/cs-etm.c:1436:20: error: invalid type argument of ‘->’ (have ‘struct
itrace_synth_opts’)
etm->synth_opts->default_no_sample);
^~
I tried this diff, and it built:
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0296405f38b2..3b37d66dc533 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1433,7 +1433,7 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->synth_opts = *session->itrace_synth_opts;
} else {
itrace_synth_opts__set_default(>synth_opts,
- etm->synth_opts->default_no_sample);
+ session->itrace_synth_opts->default_no_sample);
etm->synth_opts.callchain = false;
}
So please incorporate it in this patch.
FYI, building-in cs-etm decoding into perf depends on
CONFIG_LIBOPENCSD. Debian has a package 'libopencsd' that provides
it. I don't know about other distros, but it's possible to build and
install the library from scratch:
https://github.com/Linaro/OpenCSD/
Thanks,
Kim
Re: [PATCH v4 6/8] perf, tools, script: Make itrace script default to all calls
On Mon, 3 Sep 2018 09:22:47 -0700
Andi Kleen wrote:
> Fix ETM build failure
> ---
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 2ae640257fdb..0296405f38b2 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -1432,7 +1432,8 @@ int cs_etm__process_auxtrace_info(union perf_event
> *event,
> if (session->itrace_synth_opts && session->itrace_synth_opts->set) {
> etm->synth_opts = *session->itrace_synth_opts;
> } else {
> - itrace_synth_opts__set_default(>synth_opts);
> + itrace_synth_opts__set_default(>synth_opts,
> + etm->synth_opts->default_no_sample);
This still fails but with a different error:
CC util/cs-etm.o
util/cs-etm.c: In function ‘cs_etm__process_auxtrace_info’:
util/cs-etm.c:1436:20: error: invalid type argument of ‘->’ (have ‘struct
itrace_synth_opts’)
etm->synth_opts->default_no_sample);
^~
I tried this diff, and it built:
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0296405f38b2..3b37d66dc533 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1433,7 +1433,7 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->synth_opts = *session->itrace_synth_opts;
} else {
itrace_synth_opts__set_default(>synth_opts,
- etm->synth_opts->default_no_sample);
+ session->itrace_synth_opts->default_no_sample);
etm->synth_opts.callchain = false;
}
So please incorporate it in this patch.
FYI, building-in cs-etm decoding into perf depends on
CONFIG_LIBOPENCSD. Debian has a package 'libopencsd' that provides
it. I don't know about other distros, but it's possible to build and
install the library from scratch:
https://github.com/Linaro/OpenCSD/
Thanks,
Kim
Re: Make perf script easier to use for itrace
On Fri, 31 Aug 2018 15:01:56 -0700 Andi Kleen wrote: > Also available in > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git > pt/easy-script-2 > > v1: Initial post > v2: Address review comments. Minor fixes to descriptions. Now builds > everywhere. OK, I grabbed the pt/easy-script-2 branch (commit 4c69fd388e17), and see build failures for a 'make -C perf' build using gcc version 7.3.0 (Ubuntu 18.04): builtin-script.c: In function ‘parse_output_fields’: builtin-script.c:2571:22: error: array subscript is above array bounds [-Werror=array-bounds] output[j].fields &= ~all_output_options[i].field; ^~ builtin-script.c:2571:22: error: array subscript is above array bounds [-Werror=array-bounds] output[j].fields &= ~all_output_options[i].field; ~^~~ builtin-script.c:2574:10: error: array subscript is above array bounds [-Werror=array-bounds] output[j].user_set = true; ~~^~~ builtin-script.c:2575:10: error: array subscript is above array bounds [-Werror=array-bounds] output[j].wildcard_set = true; ~~^~~ ... util/cs-etm.c: In function ‘cs_etm__process_auxtrace_info’: util/cs-etm.c:1436:14: error: ‘struct perf_session’ has no member named ‘itrace_synth’; did you mean ‘itrace_synth_opts’? session->itrace_synth.default_no_sample); ^~~~ itrace_synth_opts Thanks, Kim p.s. FWIW, my make VF=1 output: Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... backtrace: [ on ] ...fortify-source: [ on ] ... sync-compare-and-swap: [ on ] ... gtk2-infobar: [ on ] ... libelf-getphdrnum: [ on ] ... libelf-gelf_getnote: [ on ] ... libelf-getshdrstrndx: [ on ] ... libelf-mmap: [ on ] ... libpython-version: [ on ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ on ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ OFF ] ... pthread-attr-setaffinity-np: [ on ] ... pthread-barrier: [ on ] ...stackprotector-all: [ on ] ... timerfd: [ on ] ... sched_getcpu: [ on ] ... sdt: [ on ] ... setns: [ on ] ...libopencsd: [ on ] ...bionic: [ OFF ] ...compile-32: [ OFF ] ... compile-x32: [ OFF ] ...cplus-demangle: [ on ] ... hello: [ OFF ] ... libbabeltrace: [ on ] ... liberty: [ on ] ... liberty-z: [ on ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] ... llvm: [ OFF ] ... llvm-version: [ OFF ] ... clang: [ OFF ] ...prefix: /home/kim ...bindir: /home/kim/bin ...libdir: /home/kim/lib64 ...sysconfdir: /home/kim/etc ... LIBUNWIND_DIR: ... LIBDW_DIR: ... JDIR: /usr/lib/jvm/java-1.8.0-openjdk-amd64 ... DWARF post unwind library: libunwind
Re: Make perf script easier to use for itrace
On Fri, 31 Aug 2018 15:01:56 -0700 Andi Kleen wrote: > Also available in > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git > pt/easy-script-2 > > v1: Initial post > v2: Address review comments. Minor fixes to descriptions. Now builds > everywhere. OK, I grabbed the pt/easy-script-2 branch (commit 4c69fd388e17), and see build failures for a 'make -C perf' build using gcc version 7.3.0 (Ubuntu 18.04): builtin-script.c: In function ‘parse_output_fields’: builtin-script.c:2571:22: error: array subscript is above array bounds [-Werror=array-bounds] output[j].fields &= ~all_output_options[i].field; ^~ builtin-script.c:2571:22: error: array subscript is above array bounds [-Werror=array-bounds] output[j].fields &= ~all_output_options[i].field; ~^~~ builtin-script.c:2574:10: error: array subscript is above array bounds [-Werror=array-bounds] output[j].user_set = true; ~~^~~ builtin-script.c:2575:10: error: array subscript is above array bounds [-Werror=array-bounds] output[j].wildcard_set = true; ~~^~~ ... util/cs-etm.c: In function ‘cs_etm__process_auxtrace_info’: util/cs-etm.c:1436:14: error: ‘struct perf_session’ has no member named ‘itrace_synth’; did you mean ‘itrace_synth_opts’? session->itrace_synth.default_no_sample); ^~~~ itrace_synth_opts Thanks, Kim p.s. FWIW, my make VF=1 output: Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ...numa_num_possible_cpus: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libcrypto: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ on ] ... get_cpuid: [ on ] ... bpf: [ on ] ... backtrace: [ on ] ...fortify-source: [ on ] ... sync-compare-and-swap: [ on ] ... gtk2-infobar: [ on ] ... libelf-getphdrnum: [ on ] ... libelf-gelf_getnote: [ on ] ... libelf-getshdrstrndx: [ on ] ... libelf-mmap: [ on ] ... libpython-version: [ on ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ on ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ OFF ] ... pthread-attr-setaffinity-np: [ on ] ... pthread-barrier: [ on ] ...stackprotector-all: [ on ] ... timerfd: [ on ] ... sched_getcpu: [ on ] ... sdt: [ on ] ... setns: [ on ] ...libopencsd: [ on ] ...bionic: [ OFF ] ...compile-32: [ OFF ] ... compile-x32: [ OFF ] ...cplus-demangle: [ on ] ... hello: [ OFF ] ... libbabeltrace: [ on ] ... liberty: [ on ] ... liberty-z: [ on ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] ... llvm: [ OFF ] ... llvm-version: [ OFF ] ... clang: [ OFF ] ...prefix: /home/kim ...bindir: /home/kim/bin ...libdir: /home/kim/lib64 ...sysconfdir: /home/kim/etc ... LIBUNWIND_DIR: ... LIBDW_DIR: ... JDIR: /usr/lib/jvm/java-1.8.0-openjdk-amd64 ... DWARF post unwind library: libunwind
Re: [PATCH v2] perf: Support for Arm A32/T32 instruction sets in CoreSight trace
On Fri, 31 Aug 2018 14:42:00 +0100
Robert Walker wrote:
> Generally, I agree with you about breaking backward compatibility, but
> in this case I don't think there is an actual problem. As I understand
I consider it a serious problem.
> it, you're worried that perf will break for people who are using an
> older version (0.8.x) of the OpenCSD library for CoreSight trace decode
> and this patch updates the requirement to a newer version (0.9.x) to
> enable support for trace of 32-bit applications.
My problem is: every time a new feature is added, it shouldn't
force base CoreSight decode functionality to require a new version of
the library.
My second problem is: this patch implements a build-time requirement,
which is insufficient for running on machines with incompatible
versions of the library.
> There are only a few (4/5?) targets around with working support for
> CoreSight trace (and of these only Juno is the only platform with a
> devicetree in the mainline kernel), so only a few users of perf for Arm
> trace decode - most of these are people working those directly involved
> with Arm & Linaro or will be reading the coresight mailing list. Anyone
Great, then share this feature with them, but don't send a patch to
break upstream, which, in turn, goes back to many things downstream
(future distro releases on newer targets, etc.).
> working with OpenCSD will have got it from github and compiled it
> themselves, so they can update and build a new version. It's only been
No. Updating the library - no matter where one gets it from - shouldn't
have to be necessary to avoid perf build regressions.
> packaged for debian so far and testing already has the 0.9.x version
> (the 0.8.x version was only in debian for 8 days before being replaced
> by 0.9.x).
What Debian does is immaterial to upstream submissions.
How is Debian testing the library, btw? Functionality that worked in
0.8 will fail in 0.9 AFAICT.
> It would be possible to add conditional compilation flags to support
> compiling with 0.8.x, but I feel this would add too much mess to the
> code and I'd need some help in figuring out perf's feature detection
> system to generate the flags.
No, we need run-time compatibility. Build-time compatibility does not
satisfy the run-time requirements in this case.
> Given the likely small number of people
> affected and the easy upgrade path, I don't think this is worth it.
This is an upstream submission, and I wouldn't like for a single person
to ever have to experience such silently deceitful bugs.
For now, share the new feature in a personal git tree, for those that
need it.
Meanwhile, the library needs to be fixed with a run-time version
compatibility API ASAP.
Thanks,
Kim
> On 29/08/18 17:32, Kim Phillips wrote:
> > On Wed, 29 Aug 2018 15:34:16 +0100
> > Robert Walker wrote:
> >
> >> Hi Kim,
> > Hi Robert,
> >
> >> On 29/08/18 14:49, Kim Phillips wrote:
> >>> On Wed, 29 Aug 2018 10:44:23 +0100
> >>> Robert Walker wrote:
> >>>
> >>>> This patch adds support for generating instruction samples from trace of
> >>>> AArch32 programs using the A32 and T32 instruction sets.
> >>>>
> >>>> T32 has variable 2 or 4 byte instruction size, so the conversion between
> >>>> addresses and instruction counts requires extra information from the
> >>>> trace
> >>>> decoder, requiring version 0.9.1 of OpenCSD. A check for the new struct
> >>>> member has been added to the feature check for OpenCSD.
> >>>>
> >>>> Signed-off-by: Robert Walker
> >>>> ---
> >>> ...
> >>>> +++ b/tools/build/feature/test-libopencsd.c
> >>>> @@ -3,6 +3,13 @@
> >>>>
> >>>>int main(void)
> >>>>{
> >>>> +/*
> >>>> + * Requires ocsd_generic_trace_elem.num_instr_range introduced
> >>>> in
> >>>> + * OpenCSD 0.9
> >>> 0.9 != 0.9.1 in the above commit text: which is it?
> >> I'll change it to 0.9.1 if there's another version of the patch (it was
> >> introduced in 0.9, but 0.9.1 has a necessary bug fix)
> >>>> + */
> >>>> +ocsd_generic_trace_elem elem;
> >>>> +(void)elem.num_instr_range;
> >>>> +
> >>> This breaks building against older versions of OpenCSD, right?
> >>>
> >>>> (void)ocsd_get_version();
> >>> Why don't we maintain building against older versions of the library,
> >>> and use the version information to make the
Re: [PATCH v2] perf: Support for Arm A32/T32 instruction sets in CoreSight trace
On Fri, 31 Aug 2018 14:42:00 +0100
Robert Walker wrote:
> Generally, I agree with you about breaking backward compatibility, but
> in this case I don't think there is an actual problem. As I understand
I consider it a serious problem.
> it, you're worried that perf will break for people who are using an
> older version (0.8.x) of the OpenCSD library for CoreSight trace decode
> and this patch updates the requirement to a newer version (0.9.x) to
> enable support for trace of 32-bit applications.
My problem is: every time a new feature is added, it shouldn't
force base CoreSight decode functionality to require a new version of
the library.
My second problem is: this patch implements a build-time requirement,
which is insufficient for running on machines with incompatible
versions of the library.
> There are only a few (4/5?) targets around with working support for
> CoreSight trace (and of these only Juno is the only platform with a
> devicetree in the mainline kernel), so only a few users of perf for Arm
> trace decode - most of these are people working those directly involved
> with Arm & Linaro or will be reading the coresight mailing list. Anyone
Great, then share this feature with them, but don't send a patch to
break upstream, which, in turn, goes back to many things downstream
(future distro releases on newer targets, etc.).
> working with OpenCSD will have got it from github and compiled it
> themselves, so they can update and build a new version. It's only been
No. Updating the library - no matter where one gets it from - shouldn't
have to be necessary to avoid perf build regressions.
> packaged for debian so far and testing already has the 0.9.x version
> (the 0.8.x version was only in debian for 8 days before being replaced
> by 0.9.x).
What Debian does is immaterial to upstream submissions.
How is Debian testing the library, btw? Functionality that worked in
0.8 will fail in 0.9 AFAICT.
> It would be possible to add conditional compilation flags to support
> compiling with 0.8.x, but I feel this would add too much mess to the
> code and I'd need some help in figuring out perf's feature detection
> system to generate the flags.
No, we need run-time compatibility. Build-time compatibility does not
satisfy the run-time requirements in this case.
> Given the likely small number of people
> affected and the easy upgrade path, I don't think this is worth it.
This is an upstream submission, and I wouldn't like for a single person
to ever have to experience such silently deceitful bugs.
For now, share the new feature in a personal git tree, for those that
need it.
Meanwhile, the library needs to be fixed with a run-time version
compatibility API ASAP.
Thanks,
Kim
> On 29/08/18 17:32, Kim Phillips wrote:
> > On Wed, 29 Aug 2018 15:34:16 +0100
> > Robert Walker wrote:
> >
> >> Hi Kim,
> > Hi Robert,
> >
> >> On 29/08/18 14:49, Kim Phillips wrote:
> >>> On Wed, 29 Aug 2018 10:44:23 +0100
> >>> Robert Walker wrote:
> >>>
> >>>> This patch adds support for generating instruction samples from trace of
> >>>> AArch32 programs using the A32 and T32 instruction sets.
> >>>>
> >>>> T32 has variable 2 or 4 byte instruction size, so the conversion between
> >>>> addresses and instruction counts requires extra information from the
> >>>> trace
> >>>> decoder, requiring version 0.9.1 of OpenCSD. A check for the new struct
> >>>> member has been added to the feature check for OpenCSD.
> >>>>
> >>>> Signed-off-by: Robert Walker
> >>>> ---
> >>> ...
> >>>> +++ b/tools/build/feature/test-libopencsd.c
> >>>> @@ -3,6 +3,13 @@
> >>>>
> >>>>int main(void)
> >>>>{
> >>>> +/*
> >>>> + * Requires ocsd_generic_trace_elem.num_instr_range introduced
> >>>> in
> >>>> + * OpenCSD 0.9
> >>> 0.9 != 0.9.1 in the above commit text: which is it?
> >> I'll change it to 0.9.1 if there's another version of the patch (it was
> >> introduced in 0.9, but 0.9.1 has a necessary bug fix)
> >>>> + */
> >>>> +ocsd_generic_trace_elem elem;
> >>>> +(void)elem.num_instr_range;
> >>>> +
> >>> This breaks building against older versions of OpenCSD, right?
> >>>
> >>>> (void)ocsd_get_version();
> >>> Why don't we maintain building against older versions of the library,
> >>> and use the version information to make the
Re: [PATCH v2] perf: Support for Arm A32/T32 instruction sets in CoreSight trace
On Wed, 29 Aug 2018 15:34:16 +0100
Robert Walker wrote:
> Hi Kim,
Hi Robert,
> On 29/08/18 14:49, Kim Phillips wrote:
> > On Wed, 29 Aug 2018 10:44:23 +0100
> > Robert Walker wrote:
> >
> >> This patch adds support for generating instruction samples from trace of
> >> AArch32 programs using the A32 and T32 instruction sets.
> >>
> >> T32 has variable 2 or 4 byte instruction size, so the conversion between
> >> addresses and instruction counts requires extra information from the trace
> >> decoder, requiring version 0.9.1 of OpenCSD. A check for the new struct
> >> member has been added to the feature check for OpenCSD.
> >>
> >> Signed-off-by: Robert Walker
> >> ---
> > ...
> >> +++ b/tools/build/feature/test-libopencsd.c
> >> @@ -3,6 +3,13 @@
> >>
> >> int main(void)
> >> {
> >> + /*
> >> + * Requires ocsd_generic_trace_elem.num_instr_range introduced in
> >> + * OpenCSD 0.9
> > 0.9 != 0.9.1 in the above commit text: which is it?
> I'll change it to 0.9.1 if there's another version of the patch (it was
> introduced in 0.9, but 0.9.1 has a necessary bug fix)
> >> + */
> >> + ocsd_generic_trace_elem elem;
> >> + (void)elem.num_instr_range;
> >> +
> > This breaks building against older versions of OpenCSD, right?
> >
> >>(void)ocsd_get_version();
> > Why don't we maintain building against older versions of the library,
> > and use the version information to make the decision on whether to use
> > the new feature being introduced in this patch?
> The intention is to fail the feature detection check if the older
> version is installed - perf will still compile, but without the
> CoreSight trace support.
It should still compile, and with CoreSight trace support, just
not support for A32/T32 instruction sets. The user shouldn't be denied
CoreSight trace support if they don't care for A32/T32 ISA support.
> OpenCSD is still in development, so new features like this are being
> added and it would add a lot of #ifdef mess to the perf code to continue
> to support any machines with the old library version installed - there
Even adding #ifdefs, that won't survive taking one perf executable
built on one machine and running it on another machine with a different
version of the OpenCSD library: it'll break inconspicuously, not
gracefully!
There needs to be a run-time means of working with older versions of
the library.
Consider checking the sizeof some of the structs? IIRC, some of the
structs sizes changed in the library. See e.g., the 'size' field of
perf_event_attr:
size
The size of the perf_event_attr structure for forward/backward
compatibility. Set this using sizeof(struct perf_event_attr)
to allow the kernel to see the struct size at the time
of compilation.
or, likely better, the 'version' and 'compat_version' of the
perf_event_mmap_page structure:
struct perf_event_mmap_page {
__u32 version;/* version number of this structure */
__u32 compat_version; /* lowest version this is compat with */
...
> will only be a handful of machines affected and it's trivial to upgrade
> them (the new Debian packages are available).
This is upstream linux, so I don't know how you know only a 'handful'
of machines affected, and I wouldn't assume everyone's using Debian.
For one, I'd hate to see a single user affected if it isn't necessary,
as is in this case - not everyone wants A32/T32 ISA support, and
library compatibility needn't be broken.
This 'screw compatibility' mentality needs to be dropped *now* if
CoreSight support is to have a successful future.
Otherwise, I suggest keeping this feature in downstream trees for the
'handful', until the library and perf code are rewritten in a state
where they properly interoperate, and do not break each other.
> How long would we
> continue to support such an older version?
What do you mean such an older version? The project's v0.9.0 commit
was on 20 June 2018, the one that's usable - v0.9.1 - has a July 27
2018 commit date! One month is *not* *old*!
> I also don't see any
> precedent for supporting multiple dependent library versions in perf.
That's because perf doesn't have a precedent on depending on libraries
that flat-out break their own users compatibility across versions ;)
Thanks,
Kim
Re: [PATCH v2] perf: Support for Arm A32/T32 instruction sets in CoreSight trace
On Wed, 29 Aug 2018 15:34:16 +0100
Robert Walker wrote:
> Hi Kim,
Hi Robert,
> On 29/08/18 14:49, Kim Phillips wrote:
> > On Wed, 29 Aug 2018 10:44:23 +0100
> > Robert Walker wrote:
> >
> >> This patch adds support for generating instruction samples from trace of
> >> AArch32 programs using the A32 and T32 instruction sets.
> >>
> >> T32 has variable 2 or 4 byte instruction size, so the conversion between
> >> addresses and instruction counts requires extra information from the trace
> >> decoder, requiring version 0.9.1 of OpenCSD. A check for the new struct
> >> member has been added to the feature check for OpenCSD.
> >>
> >> Signed-off-by: Robert Walker
> >> ---
> > ...
> >> +++ b/tools/build/feature/test-libopencsd.c
> >> @@ -3,6 +3,13 @@
> >>
> >> int main(void)
> >> {
> >> + /*
> >> + * Requires ocsd_generic_trace_elem.num_instr_range introduced in
> >> + * OpenCSD 0.9
> > 0.9 != 0.9.1 in the above commit text: which is it?
> I'll change it to 0.9.1 if there's another version of the patch (it was
> introduced in 0.9, but 0.9.1 has a necessary bug fix)
> >> + */
> >> + ocsd_generic_trace_elem elem;
> >> + (void)elem.num_instr_range;
> >> +
> > This breaks building against older versions of OpenCSD, right?
> >
> >>(void)ocsd_get_version();
> > Why don't we maintain building against older versions of the library,
> > and use the version information to make the decision on whether to use
> > the new feature being introduced in this patch?
> The intention is to fail the feature detection check if the older
> version is installed - perf will still compile, but without the
> CoreSight trace support.
It should still compile, and with CoreSight trace support, just
not support for A32/T32 instruction sets. The user shouldn't be denied
CoreSight trace support if they don't care for A32/T32 ISA support.
> OpenCSD is still in development, so new features like this are being
> added and it would add a lot of #ifdef mess to the perf code to continue
> to support any machines with the old library version installed - there
Even adding #ifdefs, that won't survive taking one perf executable
built on one machine and running it on another machine with a different
version of the OpenCSD library: it'll break inconspicuously, not
gracefully!
There needs to be a run-time means of working with older versions of
the library.
Consider checking the sizeof some of the structs? IIRC, some of the
structs sizes changed in the library. See e.g., the 'size' field of
perf_event_attr:
size
The size of the perf_event_attr structure for forward/backward
compatibility. Set this using sizeof(struct perf_event_attr)
to allow the kernel to see the struct size at the time
of compilation.
or, likely better, the 'version' and 'compat_version' of the
perf_event_mmap_page structure:
struct perf_event_mmap_page {
__u32 version;/* version number of this structure */
__u32 compat_version; /* lowest version this is compat with */
...
> will only be a handful of machines affected and it's trivial to upgrade
> them (the new Debian packages are available).
This is upstream linux, so I don't know how you know only a 'handful'
of machines affected, and I wouldn't assume everyone's using Debian.
For one, I'd hate to see a single user affected if it isn't necessary,
as is in this case - not everyone wants A32/T32 ISA support, and
library compatibility needn't be broken.
This 'screw compatibility' mentality needs to be dropped *now* if
CoreSight support is to have a successful future.
Otherwise, I suggest keeping this feature in downstream trees for the
'handful', until the library and perf code are rewritten in a state
where they properly interoperate, and do not break each other.
> How long would we
> continue to support such an older version?
What do you mean such an older version? The project's v0.9.0 commit
was on 20 June 2018, the one that's usable - v0.9.1 - has a July 27
2018 commit date! One month is *not* *old*!
> I also don't see any
> precedent for supporting multiple dependent library versions in perf.
That's because perf doesn't have a precedent on depending on libraries
that flat-out break their own users compatibility across versions ;)
Thanks,
Kim
Re: [PATCH v2] perf: Support for Arm A32/T32 instruction sets in CoreSight trace
On Wed, 29 Aug 2018 10:44:23 +0100
Robert Walker wrote:
> This patch adds support for generating instruction samples from trace of
> AArch32 programs using the A32 and T32 instruction sets.
>
> T32 has variable 2 or 4 byte instruction size, so the conversion between
> addresses and instruction counts requires extra information from the trace
> decoder, requiring version 0.9.1 of OpenCSD. A check for the new struct
> member has been added to the feature check for OpenCSD.
>
> Signed-off-by: Robert Walker
> ---
...
> +++ b/tools/build/feature/test-libopencsd.c
> @@ -3,6 +3,13 @@
>
> int main(void)
> {
> + /*
> + * Requires ocsd_generic_trace_elem.num_instr_range introduced in
> + * OpenCSD 0.9
0.9 != 0.9.1 in the above commit text: which is it?
> + */
> + ocsd_generic_trace_elem elem;
> + (void)elem.num_instr_range;
> +
This breaks building against older versions of OpenCSD, right?
> (void)ocsd_get_version();
Why don't we maintain building against older versions of the library,
and use the version information to make the decision on whether to use
the new feature being introduced in this patch?
Thanks,
Kim
Re: [PATCH v2] perf: Support for Arm A32/T32 instruction sets in CoreSight trace
On Wed, 29 Aug 2018 10:44:23 +0100
Robert Walker wrote:
> This patch adds support for generating instruction samples from trace of
> AArch32 programs using the A32 and T32 instruction sets.
>
> T32 has variable 2 or 4 byte instruction size, so the conversion between
> addresses and instruction counts requires extra information from the trace
> decoder, requiring version 0.9.1 of OpenCSD. A check for the new struct
> member has been added to the feature check for OpenCSD.
>
> Signed-off-by: Robert Walker
> ---
...
> +++ b/tools/build/feature/test-libopencsd.c
> @@ -3,6 +3,13 @@
>
> int main(void)
> {
> + /*
> + * Requires ocsd_generic_trace_elem.num_instr_range introduced in
> + * OpenCSD 0.9
0.9 != 0.9.1 in the above commit text: which is it?
> + */
> + ocsd_generic_trace_elem elem;
> + (void)elem.num_instr_range;
> +
This breaks building against older versions of OpenCSD, right?
> (void)ocsd_get_version();
Why don't we maintain building against older versions of the library,
and use the version information to make the decision on whether to use
the new feature being introduced in this patch?
Thanks,
Kim
Re: [PATCH v4 0/2]: perf: reduce data loss when profiling highly parallel CPU bound workloads
On Tue, 28 Aug 2018 18:44:57 +0300
Alexey Budankov wrote:
> Experiment with profiling matrix multiplication code executing 128
> threads on Intel Xeon Phi (KNM) with 272 cores, like below,
> demonstrates data loss metrics value of 98%:
So I took these two patches for a quick test-drive on intel-pt.
BEFORE (acme's today's perf/core branch):
$ sudo perf version
perf version 4.18.rc7.g55fc647
$ sudo perf record -e intel_pt// dd if=/dev/zero of=/dev/null count=10
10+0 records in
10+0 records out
5120 bytes (51 MB, 49 MiB) copied, 0.0868081 s, 590 MB/s
[ perf record: Woken up 21 times to write data ]
[ perf record: Captured and wrote 41.302 MB perf.data ]
$
AFTER (== BEFORE + these two patches):
$ sudo ./perf version
perf version 4.18.rc7.gbc1c99
$ sudo perf record -e intel_pt// dd if=/dev/zero of=/dev/null count=10
10+0 records in
10+0 records out
5120 bytes (51 MB, 49 MiB) copied, 0.0931142 s, 550 MB/s
...and it's still running, minutes afterwards. Before I kill it,
here's some strace output:
nanosleep({tv_sec=0, tv_nsec=50}, NULL) = 0
lseek(3, 332556518, SEEK_SET) = 332556518
write(3, "D\0\0\0\0\0\10\0", 8) = 8
lseek(3, 0, SEEK_CUR) = 332556526
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
nanosleep({tv_sec=0, tv_nsec=50}, NULL) = 0
lseek(3, 332578462, SEEK_SET) = 332578462
write(3, "D\0\0\0\0\0\10\0", 8) = 8
lseek(3, 0, SEEK_CUR) = 332578470
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
nanosleep({tv_sec=0, tv_nsec=50}, NULL) = 0
lseek(3, 332598822, SEEK_SET) = 332598822
write(3, "D\0\0\0\0\0\10\0", 8) = 8
lseek(3, 0, SEEK_CUR) = 332598830
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
^Cstrace: Process 3597 detached
I can't prove that it's these two patches that create the hang, but
this does look like a livelock situation...hm, hitting ^C doesn't stop
it...had to kill -9 it...erm, does 'perf record -e intel_pt// dd...'
work for you on a more standard machine?:
$ dmesg | grep Perf
[0.044226] Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR,
full-width counters, Intel PMU driver.
Thanks,
Kim
Re: [PATCH v4 0/2]: perf: reduce data loss when profiling highly parallel CPU bound workloads
On Tue, 28 Aug 2018 18:44:57 +0300
Alexey Budankov wrote:
> Experiment with profiling matrix multiplication code executing 128
> threads on Intel Xeon Phi (KNM) with 272 cores, like below,
> demonstrates data loss metrics value of 98%:
So I took these two patches for a quick test-drive on intel-pt.
BEFORE (acme's today's perf/core branch):
$ sudo perf version
perf version 4.18.rc7.g55fc647
$ sudo perf record -e intel_pt// dd if=/dev/zero of=/dev/null count=10
10+0 records in
10+0 records out
5120 bytes (51 MB, 49 MiB) copied, 0.0868081 s, 590 MB/s
[ perf record: Woken up 21 times to write data ]
[ perf record: Captured and wrote 41.302 MB perf.data ]
$
AFTER (== BEFORE + these two patches):
$ sudo ./perf version
perf version 4.18.rc7.gbc1c99
$ sudo perf record -e intel_pt// dd if=/dev/zero of=/dev/null count=10
10+0 records in
10+0 records out
5120 bytes (51 MB, 49 MiB) copied, 0.0931142 s, 550 MB/s
...and it's still running, minutes afterwards. Before I kill it,
here's some strace output:
nanosleep({tv_sec=0, tv_nsec=50}, NULL) = 0
lseek(3, 332556518, SEEK_SET) = 332556518
write(3, "D\0\0\0\0\0\10\0", 8) = 8
lseek(3, 0, SEEK_CUR) = 332556526
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
nanosleep({tv_sec=0, tv_nsec=50}, NULL) = 0
lseek(3, 332578462, SEEK_SET) = 332578462
write(3, "D\0\0\0\0\0\10\0", 8) = 8
lseek(3, 0, SEEK_CUR) = 332578470
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
nanosleep({tv_sec=0, tv_nsec=50}, NULL) = 0
lseek(3, 332598822, SEEK_SET) = 332598822
write(3, "D\0\0\0\0\0\10\0", 8) = 8
lseek(3, 0, SEEK_CUR) = 332598830
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252c8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e725200, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f221e7252cc, FUTEX_WAKE_PRIVATE, 1) = 1
^Cstrace: Process 3597 detached
I can't prove that it's these two patches that create the hang, but
this does look like a livelock situation...hm, hitting ^C doesn't stop
it...had to kill -9 it...erm, does 'perf record -e intel_pt// dd...'
work for you on a more standard machine?:
$ dmesg | grep Perf
[0.044226] Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR,
full-width counters, Intel PMU driver.
Thanks,
Kim
[PATCH] perf annotate: Handle arm64 move instructions
Add default handler for non-jump instructions. This really only has an
effect on instructions that compute a PC-relative address, such as 'adrp,'
as seen in these couple of examples:
BEFORE: adrp x0, 2aa11000
AFTER: adrp x0, kallsyms_token_index+0xce000
BEFORE: adrp x23, 2ae94000 <__per_cpu_load>
AFTER: adrp x23, __per_cpu_load
The implementation is identical to that of s390, but with a slight
adjustment for objdump whitespace propagation (arm64 objdump puts
spaces after commas, whereas s390's presumably doesn't).
The mov__scnprintf() declaration is moved from s390's to arm64's
instructions.c because arm64's gets included before s390's.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Thomas Richter
Cc: Hendrik Brueckner
Signed-off-by: Kim Phillips
---
tools/perf/arch/arm64/annotate/instructions.c | 59 ++-
tools/perf/arch/s390/annotate/instructions.c | 2 -
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/arm64/annotate/instructions.c
b/tools/perf/arch/arm64/annotate/instructions.c
index 6688977e4ac7..76c6345a57d5 100644
--- a/tools/perf/arch/arm64/annotate/instructions.c
+++ b/tools/perf/arch/arm64/annotate/instructions.c
@@ -8,6 +8,63 @@ struct arm64_annotate {
jump_insn;
};
+static int arm64_mov__parse(struct arch *arch __maybe_unused,
+ struct ins_operands *ops,
+ struct map_symbol *ms __maybe_unused)
+{
+ char *s = strchr(ops->raw, ','), *target, *endptr;
+
+ if (s == NULL)
+ return -1;
+
+ *s = '\0';
+ ops->source.raw = strdup(ops->raw);
+ *s = ',';
+
+ if (ops->source.raw == NULL)
+ return -1;
+
+ target = ++s;
+ ops->target.raw = strdup(target);
+ if (ops->target.raw == NULL)
+ goto out_free_source;
+
+ ops->target.addr = strtoull(target, , 16);
+ if (endptr == target)
+ goto out_free_target;
+
+ s = strchr(endptr, '<');
+ if (s == NULL)
+ goto out_free_target;
+ endptr = strchr(s + 1, '>');
+ if (endptr == NULL)
+ goto out_free_target;
+
+ *endptr = '\0';
+ *s = ' ';
+ ops->target.name = strdup(s);
+ *s = '<';
+ *endptr = '>';
+ if (ops->target.name == NULL)
+ goto out_free_target;
+
+ return 0;
+
+out_free_target:
+ zfree(>target.raw);
+out_free_source:
+ zfree(>source.raw);
+ return -1;
+}
+
+static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
+ struct ins_operands *ops);
+
+static struct ins_ops arm64_mov_ops = {
+ .parse = arm64_mov__parse,
+ .scnprintf = mov__scnprintf,
+};
+
static struct ins_ops *arm64__associate_instruction_ops(struct arch *arch,
const char *name)
{
struct arm64_annotate *arm = arch->priv;
@@ -21,7 +78,7 @@ static struct ins_ops
*arm64__associate_instruction_ops(struct arch *arch, const
else if (!strcmp(name, "ret"))
ops = _ops;
else
- return NULL;
+ ops = _mov_ops;
arch__associate_ins_ops(arch, name, ops);
return ops;
diff --git a/tools/perf/arch/s390/annotate/instructions.c
b/tools/perf/arch/s390/annotate/instructions.c
index cee4e2f7c057..de0dd66dbb48 100644
--- a/tools/perf/arch/s390/annotate/instructions.c
+++ b/tools/perf/arch/s390/annotate/instructions.c
@@ -100,8 +100,6 @@ static int s390_mov__parse(struct arch *arch __maybe_unused,
return -1;
}
-static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
- struct ins_operands *ops);
static struct ins_ops s390_mov_ops = {
.parse = s390_mov__parse,
--
2.17.1
[PATCH] perf annotate: Handle arm64 move instructions
Add default handler for non-jump instructions. This really only has an
effect on instructions that compute a PC-relative address, such as 'adrp,'
as seen in these couple of examples:
BEFORE: adrp x0, 2aa11000
AFTER: adrp x0, kallsyms_token_index+0xce000
BEFORE: adrp x23, 2ae94000 <__per_cpu_load>
AFTER: adrp x23, __per_cpu_load
The implementation is identical to that of s390, but with a slight
adjustment for objdump whitespace propagation (arm64 objdump puts
spaces after commas, whereas s390's presumably doesn't).
The mov__scnprintf() declaration is moved from s390's to arm64's
instructions.c because arm64's gets included before s390's.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Thomas Gleixner
Cc: Greg Kroah-Hartman
Cc: Thomas Richter
Cc: Hendrik Brueckner
Signed-off-by: Kim Phillips
---
tools/perf/arch/arm64/annotate/instructions.c | 59 ++-
tools/perf/arch/s390/annotate/instructions.c | 2 -
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/tools/perf/arch/arm64/annotate/instructions.c
b/tools/perf/arch/arm64/annotate/instructions.c
index 6688977e4ac7..76c6345a57d5 100644
--- a/tools/perf/arch/arm64/annotate/instructions.c
+++ b/tools/perf/arch/arm64/annotate/instructions.c
@@ -8,6 +8,63 @@ struct arm64_annotate {
jump_insn;
};
+static int arm64_mov__parse(struct arch *arch __maybe_unused,
+ struct ins_operands *ops,
+ struct map_symbol *ms __maybe_unused)
+{
+ char *s = strchr(ops->raw, ','), *target, *endptr;
+
+ if (s == NULL)
+ return -1;
+
+ *s = '\0';
+ ops->source.raw = strdup(ops->raw);
+ *s = ',';
+
+ if (ops->source.raw == NULL)
+ return -1;
+
+ target = ++s;
+ ops->target.raw = strdup(target);
+ if (ops->target.raw == NULL)
+ goto out_free_source;
+
+ ops->target.addr = strtoull(target, , 16);
+ if (endptr == target)
+ goto out_free_target;
+
+ s = strchr(endptr, '<');
+ if (s == NULL)
+ goto out_free_target;
+ endptr = strchr(s + 1, '>');
+ if (endptr == NULL)
+ goto out_free_target;
+
+ *endptr = '\0';
+ *s = ' ';
+ ops->target.name = strdup(s);
+ *s = '<';
+ *endptr = '>';
+ if (ops->target.name == NULL)
+ goto out_free_target;
+
+ return 0;
+
+out_free_target:
+ zfree(>target.raw);
+out_free_source:
+ zfree(>source.raw);
+ return -1;
+}
+
+static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
+ struct ins_operands *ops);
+
+static struct ins_ops arm64_mov_ops = {
+ .parse = arm64_mov__parse,
+ .scnprintf = mov__scnprintf,
+};
+
static struct ins_ops *arm64__associate_instruction_ops(struct arch *arch,
const char *name)
{
struct arm64_annotate *arm = arch->priv;
@@ -21,7 +78,7 @@ static struct ins_ops
*arm64__associate_instruction_ops(struct arch *arch, const
else if (!strcmp(name, "ret"))
ops = _ops;
else
- return NULL;
+ ops = _mov_ops;
arch__associate_ins_ops(arch, name, ops);
return ops;
diff --git a/tools/perf/arch/s390/annotate/instructions.c
b/tools/perf/arch/s390/annotate/instructions.c
index cee4e2f7c057..de0dd66dbb48 100644
--- a/tools/perf/arch/s390/annotate/instructions.c
+++ b/tools/perf/arch/s390/annotate/instructions.c
@@ -100,8 +100,6 @@ static int s390_mov__parse(struct arch *arch __maybe_unused,
return -1;
}
-static int mov__scnprintf(struct ins *ins, char *bf, size_t size,
- struct ins_operands *ops);
static struct ins_ops s390_mov_ops = {
.parse = s390_mov__parse,
--
2.17.1
[PATCH v2] perf annotate: fix parsing aarch64 branch instructions after objdump update
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code [1].
It is assumed that commas in objdump comments could occur in other arches
now or in the future, so this fix is arch-independent.
The fix could have been done with arm64 specific jump__parse and
jump__scnprintf functions, but the jump__scnprintf instruction would
have to have its comment character be a literal, since the scnprintf
functions cannot receive a struct arch easily.
This inconvenience also applies to the generic jump__scnprintf, which
is why we add a raw_comment pointer to struct ins_operands, so the
__parse function assigns it to be re-used by its corresponding __scnprintf
function.
Example differences in 'perf annotate --stdio2' output on an
aarch64 perf.data file:
BEFORE: → b.cs 28133d1c // b.hs, d7ecc47b
AFTER : ↓ b.cs 18c
BEFORE: → b.cc 28d8d9cc // b.lo, b.ul,
d727295b
AFTER : ↓ b.cc 31c
The branch target labels 18c and 31c also now appear in the output:
BEFORE:addx26, x29, #0x80
AFTER : 18c: addx26, x29, #0x80
BEFORE:addx21, x21, #0x8
AFTER : 31c: addx21, x21, #0x8
The Fixes: tag below is added so stable branches will get the update; it
doesn't necessarily mean that commit was broken at the time, rather it
didn't withstand the aarch64 objdump update.
Tested no difference in output for sample x86_64, power arch perf.data files.
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bb7eff5206e4795ac79c177a80fe9f4630aaf730
Cc: Ravi Bangoria
Cc: Anton Blanchard
Cc: Robin Murphy
Cc: Alexander Shishkin
Cc: Christian Borntraeger
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Taeung Song
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Fixes: b13bbeee5ee6 ("perf annotate: Fix branch instruction with multiple
operands")
Signed-off-by: Kim Phillips
---
v2: address acme's comments:
- consolidate into a validate_comma()
- call from an additional couple of places necessary
- don't listen to checkpatch wrt reflowing jump__parse definition
line to less than 80 characters, just rm the __maybe_unused
- re-tested no diff on x86_64 and power arch, arm64 conditional
branches fixed.
tools/perf/util/annotate.c | 22 +-
tools/perf/util/annotate.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e4268b948e0e..4a2525524e52 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -276,7 +276,19 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops || ins->ops == _call_ops;
}
-static int jump__parse(struct arch *arch __maybe_unused, struct ins_operands
*ops, struct map_symbol *ms)
+/*
+ * Prevents from matching commas in the comment section, e.g.:
+ * 28446e70: b.cs284470f4
// b.hs, b.nlast
+ */
+static inline const char *validate_comma(const char *c, struct ins_operands
*ops)
+{
+ if (ops->raw_comment && c > ops->raw_comment)
+ return NULL;
+
+ return c;
+}
+
+static int jump__parse(struct arch *arch, struct ins_operands *ops, struct
map_symbol *ms)
{
struct map *map = ms->map;
struct symbol *sym = ms->sym;
@@ -285,6 +297,10 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
};
const char *c = strchr(ops->raw, ',');
u64 start, end;
+
+ ops->raw_comment = strchr(ops->raw, arch->objdump.comment_char);
+ c = validate_comma(c, ops);
+
/*
* Examples of lines to parse for the _cpp_lex_token@@Base
* function:
@@ -304,6 +320,7 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
ops->target.addr = strtoull(c, NULL, 16);
if (!ops->target.addr) {
c = strchr(c, ',');
+ c = validate_comma(c, ops);
if (c++ != NULL)
ops->target.addr = strtoull(c, NULL, 16);
}
@@ -361,9 +378,12 @@ static int jump__scnprintf(struct ins *ins, char *bf,
size_t size,
return scnprintf(bf, size, "%-6s %s", ins->name,
ops->target.sym->name);
c = strchr(ops->raw, ',');
+ c = validate_comma(c, ops);
+
if (c != NULL) {
const char *c2 = strchr(c + 1, ',');
+ c2 = validate_comma(c2, ops);
/* check for 3-op insn */
if (c2 != NULL)
c = c2;
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 005a5fe8a8c6..5399ba2321bb 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -22,6
[PATCH v2] perf annotate: fix parsing aarch64 branch instructions after objdump update
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code [1].
It is assumed that commas in objdump comments could occur in other arches
now or in the future, so this fix is arch-independent.
The fix could have been done with arm64 specific jump__parse and
jump__scnprintf functions, but the jump__scnprintf instruction would
have to have its comment character be a literal, since the scnprintf
functions cannot receive a struct arch easily.
This inconvenience also applies to the generic jump__scnprintf, which
is why we add a raw_comment pointer to struct ins_operands, so the
__parse function assigns it to be re-used by its corresponding __scnprintf
function.
Example differences in 'perf annotate --stdio2' output on an
aarch64 perf.data file:
BEFORE: → b.cs 28133d1c // b.hs, d7ecc47b
AFTER : ↓ b.cs 18c
BEFORE: → b.cc 28d8d9cc // b.lo, b.ul,
d727295b
AFTER : ↓ b.cc 31c
The branch target labels 18c and 31c also now appear in the output:
BEFORE:addx26, x29, #0x80
AFTER : 18c: addx26, x29, #0x80
BEFORE:addx21, x21, #0x8
AFTER : 31c: addx21, x21, #0x8
The Fixes: tag below is added so stable branches will get the update; it
doesn't necessarily mean that commit was broken at the time, rather it
didn't withstand the aarch64 objdump update.
Tested no difference in output for sample x86_64, power arch perf.data files.
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bb7eff5206e4795ac79c177a80fe9f4630aaf730
Cc: Ravi Bangoria
Cc: Anton Blanchard
Cc: Robin Murphy
Cc: Alexander Shishkin
Cc: Christian Borntraeger
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Taeung Song
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Fixes: b13bbeee5ee6 ("perf annotate: Fix branch instruction with multiple
operands")
Signed-off-by: Kim Phillips
---
v2: address acme's comments:
- consolidate into a validate_comma()
- call from an additional couple of places necessary
- don't listen to checkpatch wrt reflowing jump__parse definition
line to less than 80 characters, just rm the __maybe_unused
- re-tested no diff on x86_64 and power arch, arm64 conditional
branches fixed.
tools/perf/util/annotate.c | 22 +-
tools/perf/util/annotate.h | 1 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e4268b948e0e..4a2525524e52 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -276,7 +276,19 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops || ins->ops == _call_ops;
}
-static int jump__parse(struct arch *arch __maybe_unused, struct ins_operands
*ops, struct map_symbol *ms)
+/*
+ * Prevents from matching commas in the comment section, e.g.:
+ * 28446e70: b.cs284470f4
// b.hs, b.nlast
+ */
+static inline const char *validate_comma(const char *c, struct ins_operands
*ops)
+{
+ if (ops->raw_comment && c > ops->raw_comment)
+ return NULL;
+
+ return c;
+}
+
+static int jump__parse(struct arch *arch, struct ins_operands *ops, struct
map_symbol *ms)
{
struct map *map = ms->map;
struct symbol *sym = ms->sym;
@@ -285,6 +297,10 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
};
const char *c = strchr(ops->raw, ',');
u64 start, end;
+
+ ops->raw_comment = strchr(ops->raw, arch->objdump.comment_char);
+ c = validate_comma(c, ops);
+
/*
* Examples of lines to parse for the _cpp_lex_token@@Base
* function:
@@ -304,6 +320,7 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
ops->target.addr = strtoull(c, NULL, 16);
if (!ops->target.addr) {
c = strchr(c, ',');
+ c = validate_comma(c, ops);
if (c++ != NULL)
ops->target.addr = strtoull(c, NULL, 16);
}
@@ -361,9 +378,12 @@ static int jump__scnprintf(struct ins *ins, char *bf,
size_t size,
return scnprintf(bf, size, "%-6s %s", ins->name,
ops->target.sym->name);
c = strchr(ops->raw, ',');
+ c = validate_comma(c, ops);
+
if (c != NULL) {
const char *c2 = strchr(c + 1, ',');
+ c2 = validate_comma(c2, ops);
/* check for 3-op insn */
if (c2 != NULL)
c = c2;
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 005a5fe8a8c6..5399ba2321bb 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -22,6
Re: [PATCH] perf annotate: fix parsing aarch64 branch instructions after objdump update
On Fri, 24 Aug 2018 09:59:22 +0200 Thomas-Mich Richter wrote: > On 08/24/2018 02:10 AM, Kim Phillips wrote: > > Tested no difference in output for sample x86_64, power arch perf.data > > files. > > Tested, no difference in output on s390. Just to let you know. Thanks! An official Tested-by: tag would help keep acme from guessing whether he should convert these less-officially sounding types of emails in the future. I doubt your official Tested-by implies you necessarily have had to claim you fully tested it on e.g., x86-64, esp. if your Tested-by is in such context as provided above. BTW, if you want to send me an s390 perf.data file and the file resulting from 'perf archive', and a matching vmlinux in an off-list email, I can add it to my perf-archives arsenal for future testing. Again, thanks for testing! Kim
Re: [PATCH] perf annotate: fix parsing aarch64 branch instructions after objdump update
On Fri, 24 Aug 2018 09:59:22 +0200 Thomas-Mich Richter wrote: > On 08/24/2018 02:10 AM, Kim Phillips wrote: > > Tested no difference in output for sample x86_64, power arch perf.data > > files. > > Tested, no difference in output on s390. Just to let you know. Thanks! An official Tested-by: tag would help keep acme from guessing whether he should convert these less-officially sounding types of emails in the future. I doubt your official Tested-by implies you necessarily have had to claim you fully tested it on e.g., x86-64, esp. if your Tested-by is in such context as provided above. BTW, if you want to send me an s390 perf.data file and the file resulting from 'perf archive', and a matching vmlinux in an off-list email, I can add it to my perf-archives arsenal for future testing. Again, thanks for testing! Kim
[PATCH] perf annotate: fix parsing aarch64 branch instructions after objdump update
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code [1].
It is assumed that commas in objdump comments could occur in other arches
now or in the future, so this fix is arch-independent.
The fix could have been done with arm64 specific jump__parse and
jump__scnprintf functions, but the jump__scnprintf instruction would
have to have its comment character be a literal, since the scnprintf
functions cannot receive a struct arch easily.
This inconvenience also applies to the generic jump__scnprintf, which
is why we add a raw_comment pointer to struct ins_operands, so the
__parse function assigns it to be re-used by its corresponding __scnprintf
function.
Example differences in 'perf annotate --stdio2' output on an
aarch64 perf.data file:
BEFORE: → b.cs 28133d1c // b.hs, d7ecc47b
AFTER : ↓ b.cs 18c
BEFORE: → b.cc 28d8d9cc // b.lo, b.ul,
d727295b
AFTER : ↓ b.cc 31c
The branch target labels 18c and 31c also now appear in the output:
BEFORE:addx26, x29, #0x80
AFTER : 18c: addx26, x29, #0x80
BEFORE:addx21, x21, #0x8
AFTER : 31c: addx21, x21, #0x8
The Fixes: tag below is added so stable branches will get the update; it
doesn't necessarily mean that commit was broken at the time, rather it
didn't withstand the aarch64 objdump update.
Tested no difference in output for sample x86_64, power arch perf.data files.
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bb7eff5206e4795ac79c177a80fe9f4630aaf730
Cc: Ravi Bangoria
Cc: Anton Blanchard
Cc: Robin Murphy
Cc: Alexander Shishkin
Cc: Christian Borntraeger
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Taeung Song
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Fixes: b13bbeee5ee6 ("perf annotate: Fix branch instruction with multiple
operands")
Signed-off-by: Kim Phillips
---
tools/perf/util/annotate.c | 17 -
tools/perf/util/annotate.h | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e32ead4744bd..b83897dafbb0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -282,7 +282,8 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops || ins->ops == _call_ops;
}
-static int jump__parse(struct arch *arch __maybe_unused, struct ins_operands
*ops, struct map_symbol *ms)
+static int jump__parse(struct arch *arch, struct ins_operands *ops,
+ struct map_symbol *ms)
{
struct map *map = ms->map;
struct symbol *sym = ms->sym;
@@ -291,6 +292,15 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
};
const char *c = strchr(ops->raw, ',');
u64 start, end;
+
+ /*
+* Prevent from matching commas in the comment section, e.g.:
+* 28446e70: b.cs284470f4
// b.hs, b.nlast
+*/
+ ops->raw_comment = strchr(ops->raw, arch->objdump.comment_char);
+ if (c && ops->raw_comment && c > ops->raw_comment)
+ c = NULL;
+
/*
* Examples of lines to parse for the _cpp_lex_token@@Base
* function:
@@ -367,6 +377,11 @@ static int jump__scnprintf(struct ins *ins, char *bf,
size_t size,
return scnprintf(bf, size, "%-6s %s", ins->name,
ops->target.sym->name);
c = strchr(ops->raw, ',');
+
+ /* Prevent from matching commas in the comment section */
+ if (ops->raw_comment && c && c > ops->raw_comment)
+ c = NULL;
+
if (c != NULL) {
const char *c2 = strchr(c + 1, ',');
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 005a5fe8a8c6..5399ba2321bb 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -22,6 +22,7 @@ struct ins {
struct ins_operands {
char*raw;
+ char*raw_comment;
struct {
char*raw;
char*name;
--
2.17.1
[PATCH] perf annotate: fix parsing aarch64 branch instructions after objdump update
Starting with binutils 2.28, aarch64 objdump adds comments to the
disassembly output to show the alternative names of a condition code [1].
It is assumed that commas in objdump comments could occur in other arches
now or in the future, so this fix is arch-independent.
The fix could have been done with arm64 specific jump__parse and
jump__scnprintf functions, but the jump__scnprintf instruction would
have to have its comment character be a literal, since the scnprintf
functions cannot receive a struct arch easily.
This inconvenience also applies to the generic jump__scnprintf, which
is why we add a raw_comment pointer to struct ins_operands, so the
__parse function assigns it to be re-used by its corresponding __scnprintf
function.
Example differences in 'perf annotate --stdio2' output on an
aarch64 perf.data file:
BEFORE: → b.cs 28133d1c // b.hs, d7ecc47b
AFTER : ↓ b.cs 18c
BEFORE: → b.cc 28d8d9cc // b.lo, b.ul,
d727295b
AFTER : ↓ b.cc 31c
The branch target labels 18c and 31c also now appear in the output:
BEFORE:addx26, x29, #0x80
AFTER : 18c: addx26, x29, #0x80
BEFORE:addx21, x21, #0x8
AFTER : 31c: addx21, x21, #0x8
The Fixes: tag below is added so stable branches will get the update; it
doesn't necessarily mean that commit was broken at the time, rather it
didn't withstand the aarch64 objdump update.
Tested no difference in output for sample x86_64, power arch perf.data files.
[1]
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bb7eff5206e4795ac79c177a80fe9f4630aaf730
Cc: Ravi Bangoria
Cc: Anton Blanchard
Cc: Robin Murphy
Cc: Alexander Shishkin
Cc: Christian Borntraeger
Cc: Mark Rutland
Cc: Peter Zijlstra
Cc: Taeung Song
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Namhyung Kim
Fixes: b13bbeee5ee6 ("perf annotate: Fix branch instruction with multiple
operands")
Signed-off-by: Kim Phillips
---
tools/perf/util/annotate.c | 17 -
tools/perf/util/annotate.h | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e32ead4744bd..b83897dafbb0 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -282,7 +282,8 @@ bool ins__is_call(const struct ins *ins)
return ins->ops == _ops || ins->ops == _call_ops;
}
-static int jump__parse(struct arch *arch __maybe_unused, struct ins_operands
*ops, struct map_symbol *ms)
+static int jump__parse(struct arch *arch, struct ins_operands *ops,
+ struct map_symbol *ms)
{
struct map *map = ms->map;
struct symbol *sym = ms->sym;
@@ -291,6 +292,15 @@ static int jump__parse(struct arch *arch __maybe_unused,
struct ins_operands *op
};
const char *c = strchr(ops->raw, ',');
u64 start, end;
+
+ /*
+* Prevent from matching commas in the comment section, e.g.:
+* 28446e70: b.cs284470f4
// b.hs, b.nlast
+*/
+ ops->raw_comment = strchr(ops->raw, arch->objdump.comment_char);
+ if (c && ops->raw_comment && c > ops->raw_comment)
+ c = NULL;
+
/*
* Examples of lines to parse for the _cpp_lex_token@@Base
* function:
@@ -367,6 +377,11 @@ static int jump__scnprintf(struct ins *ins, char *bf,
size_t size,
return scnprintf(bf, size, "%-6s %s", ins->name,
ops->target.sym->name);
c = strchr(ops->raw, ',');
+
+ /* Prevent from matching commas in the comment section */
+ if (ops->raw_comment && c && c > ops->raw_comment)
+ c = NULL;
+
if (c != NULL) {
const char *c2 = strchr(c + 1, ',');
diff --git a/tools/perf/util/annotate.h b/tools/perf/util/annotate.h
index 005a5fe8a8c6..5399ba2321bb 100644
--- a/tools/perf/util/annotate.h
+++ b/tools/perf/util/annotate.h
@@ -22,6 +22,7 @@ struct ins {
struct ins_operands {
char*raw;
+ char*raw_comment;
struct {
char*raw;
char*name;
--
2.17.1
Re: [PATCH] Properly interpret indirect call in perf annotate.
On Thu, 23 Aug 2018 14:29:34 +0200 Martin Liška wrote: > The patch changes interpretation of: > callq *0x8(%rbx) > > from: > 0.26 │ → callq *8 > to: > 0.26 │ → callq *0x8(%rbx) > > in this can an address is followed by a register, thus > one can't parse only address. > > Signed-off-by: Martin Liška > --- Tested this doesn't incur any grievances parsing aarch64 code: Tested-by: Kim Phillips Thanks, Kim
