commit/papi: 2 new changesets

104 views
Skip to first unread message

Bitbucket

unread,
Apr 5, 2021, 1:26:16 PM4/5/21
to perfap...@icl.utk.edu
2 new commits in papi:

https://bitbucket.org/icl/papi/commits/f9fed84c4c31/
Changeset: f9fed84c4c31
Branch: None
User: Tony_ICL
Date: 2021-03-26 18:15:23+00:00
Summary: This affects the processor AMD Zen2, we tested on it.
It affects the following processors we do not have to test on;
A64FX (Fujitsu ARM),AMD Zen3, Intel TigerLake and
RocketLake.

Update libpfm4, to be current with the following commit:

commit c132ab4948a828334a8fef00303a4b47f59bb4d9
Author: Stephane Eranian <era...@gmail.com>
Date: Tue Mar 23 10:11:40 2021 -0700

Add prefix to AMD Fam19h Zen3 L3 events

To avoid potential conflict with other core PMU events and make it
more explicit these are uncore L3 events following the model of
Intel uncore PMUs.

Signed-off-by: Stephane Eranian <era...@gmail.com>

commit a97908e8e6b6a28ae369dfbc9af97b52fe932273
Author: Stephane Eranian <era...@gmail.com>
Date: Tue Mar 23 00:31:40 2021 -0700

Enable Intel Tigerlake and Rocketlake core PMU support

They are equivalent to Intel Icelake, so reuse the
same event table.

Signed-off-by: Stephane Eranian <era...@gmail.com>

commit 315941fc05f5a487e4eb5efd36ea10438336944b
Author: Stephane Eranian <era...@gmail.com>
Date: Thu Mar 18 23:13:57 2021 -0700

add AMD64 Fam19h Zen3 L3 PMU support

This patch adds the AMD Fam19h (Zen3) L3 PMU support consisting of
3 published events.

new PMU model: amd64_fam19h_zen3_l3

Based on the public specifications PPR (#55898) Rev 0.35 - Feb 5, 2021.
Available at: https://www.amd.com/system/files/TechDocs/55898_pub.zip

Signed-off-by: Stephane Eranian <era...@gmail.com>

commit e2afb6186dab2419a4b6f79a6adf7cd9bb0f2340
Author: Stephane Eranian <era...@gmail.com>
Date: Mon Mar 15 12:04:48 2021 -0700

Add AMD64 Fam17h Zen2 RAPL support

This patch adds RAPL support for AMD64 Fam17h Zen2
processors. On Zen2, only the RAPL_ENERGY_PKGS event is supported.

Signed-off-by: Stephane Eranian <era...@gmail.com>

commit cc4ba27e55440f87359bee5176380db1ba4ef8af
Author: Swarup Sahoo <swarup-cha...@amd.com>
Date: Tue Mar 2 01:49:51 2021 +0530

Add AMD64 Fam19h Zen3 core PMU support

The patch adds a core PMU support for AMD Fam19h Zen3.

new PMU model: amd64_fam19h_zen3

Based on the public specifications PPR (#55898) Rev 0.35 - Feb 5, 2021.
Available at: https://www.amd.com/system/files/TechDocs/55898_pub.zip

Signed-off-by: Swarup Sahoo <swarup-cha...@amd.com>

commit 5333f3245954b038100530a17675bbbafdae3061
Author: Stephane Eranian <era...@gmail.com>
Date: Sun Jan 31 00:01:36 2021 -0800

Fix casting issues reported by PGI compiler

The PGI compiler does not like:
struct {
unsigned long field;
};

struct.field = -1,

So clean this up and various others casting issues reported by Carl Ponder
on the bugs.

Signed-off-by: Stephane Eranian <era...@gmail.com>

commit f6500e77563e606c8510ff26f57d321328bd8157
Author: Masahiko, Yamada <yamada....@fujitsu.com>
Date: Wed Jan 27 20:12:59 2021 +0900

Changing the number of PMU counters and deleting the ARM(32-bit) mode for A64FX

The current libpfm4 implementation treats PMCR_EL0.N = 0x6 like other ARM Reference processors.
On an A64FX, PMCR_EL0.N = 0x8 (The number of PMU counters is 8.).
Therefore, only 6 counters are available in the current implementation.
The A64FX core also supports the AArch64 state and the A64 Instruction set.
The AArch32 state and the A32, T32 Instruction set are not supported and cannot be transitioned to this Execution state.
Currently, the libpfm manual(docs/man3/libpfm_arm_a64fx.3) states that A32/A64 can be used, but A32 cannot be used.

I have created a patch with the above fixes, so please review and merge it.

Originally, the specification of the A64FX which Fujitsu published should have described the above two points,
but the description was omitted.
A64FX Specification HPC Extension v1.1 will add:.
- On a A64FX, PMCR_EL0.N = 0x8 (The number of PMU counters is 8.).
- A64FX does not support the AArch32 state and the A32, T32 Instruction set and cannot transition to this Execution state.

Affected #: 24 files

https://bitbucket.org/icl/papi/commits/55329ec980d5/
Changeset: 55329ec980d5
Branch: master
User: Tony_ICL
Date: 2021-04-05 17:26:07+00:00
Summary: Merged in master (pull request #177)

Update libpfm4 for changes on 03-23-2021.

Approved-by: Damien Genet
Approved-by: Heike Jagode

Affected #: 24 files

Repository URL: https://bitbucket.org/icl/papi/

--

This is a commit notification from bitbucket.org. You are receiving
this because you have the service enabled, addressing the recipient of
this email.

Bitbucket

unread,
Apr 7, 2021, 5:21:33 PM4/7/21
to perfap...@icl.utk.edu
2 new commits in papi:

https://bitbucket.org/icl/papi/commits/69d019cf7bb0/
Changeset: 69d019cf7bb0
Branch: None
User: Tony_ICL
Date: 2021-04-07 15:13:34+00:00
Summary: The following fixes are for AMD Zen3 CPUs, untested by ICL,
we have no access to Zen3 processors at this time.

Update libpfm4, to be current with the following commit:

commit 6864dad7cf85fac9fff04bd814026e2fbc160175
Author: Stephane Eranian <era...@gmail.com>
Date: Tue Apr 6 22:37:51 2021 -0700

Fix AMD64 Fam19h L3 PMU support

The PMU perf_events type was not correctly encoded because the .perf_name field
was not initialized and therefore it defaulted to using the core PMU. The correct
perf_name is "amd_l3". With that in place, the library now picks up the correct
PMU type and associated programming restrictions, e.g., per-cpu mode only and code
such as perf_examples/self should not be allow to succeed at perf_event_open().

Reported-by: Steve Kaufmann <steven....@hpe.com>
Signed-off-by: Stephane Eranian <era...@gmail.com>

commit 99975b4738cf7f2550922f0761f2776159842c00
Author: Stephane Eranian <era...@google.com>
Date: Fri Apr 2 12:38:56 2021 -0700

fix grpid handling for Intel X86 uncore

On SkylakeX the umask grpid field is overloaded to contain two subfield.
The actual grpid and the required grpid (at offset 8). The encoding code
has a bug where it would not use the accessor function get_grpid() to extract
the group id from the field. Given that the grpid is used in statements such
as:
u = 1 << pe[e->event].umasks[a->idx].grpid;
The code could run the risk of exceeding the max shift for a 16-bit value.
The fix is to use accessor function to extract the grpid.

The patch also adds a validation test to ensure events which would cause
a large grpid are properly encoded.

Signed-off-by: Stephane Eranian <era...@gmail.com>

Affected #: 3 files

https://bitbucket.org/icl/papi/commits/c82c661a5099/
Changeset: c82c661a5099
Branch: master
User: Tony_ICL
Date: 2021-04-07 21:21:25+00:00
Summary: Merged in master (pull request #179)

libpfm4 update incorporating latest fixes received 04-06-2021.
Update libpfm4, to be current with the following commit:

The following fixes are for AMD Zen3 CPUs, untested by ICL, we have no access to Zen3 processors at this time.

commit 6864dad7cf85fac9fff04bd814026e2fbc160175 Author: Stephane Eranian era...@gmail.com Date: Tue Apr 6 22:37:51 2021 -0700

Fix AMD64 Fam19h L3 PMU support

The PMU perf_events type was not correctly encoded because the .perf_name field
was not initialized and therefore it defaulted to using the core PMU. The correct
perf_name is "amd_l3". With that in place, the library now picks up the correct
PMU type and associated programming restrictions, e.g., per-cpu mode only and code
such as perf_examples/self should not be allow to succeed at perf_event_open().

Reported-by: Steve Kaufmann <steven....@hpe.com>
Signed-off-by: Stephane Eranian <era...@gmail.com>
commit 99975b4738cf7f2550922f0761f2776159842c00 Author: Stephane Eranian era...@google.com Date: Fri Apr 2 12:38:56 2021 -0700

fix grpid handling for Intel X86 uncore

On SkylakeX the umask grpid field is overloaded to contain two subfield.
The actual grpid and the required grpid (at offset 8). The encoding code
has a bug where it would not use the accessor function get_grpid() to extract
the group id from the field. Given that the grpid is used in statements such
as:
u = 1 << pe[e->event].umasks[a->idx].grpid;
The code could run the risk of exceeding the max shift for a 16-bit value.
The fix is to use accessor function to extract the grpid.

The patch also adds a validation test to ensure events which would cause
a large grpid are properly encoded.

Signed-off-by: Stephane Eranian <era...@gmail.com>

Approved-by: Damien Genet

Affected #: 3 files
Reply all
Reply to author
Forward
0 new messages