Re: [perfmon2] [ptools-perfapi] Avoid hardcoding the number of entries in the libpfm library with PFM_PMU_MAX

[Stephane Eranian via perfmon2-devel]

Hi Will,

On Thu, Jun 1, 2017 at 7:16 AM, William Cohen  wrote:
> On 06/01/2017 03:17 AM, Stephane Eranian wrote:
>> Hi,
>>
>> So if I understand, the problem is that you compile PAPI against a
>> libpfm which is different from the one actually installed on the
>> system. If the system has a more recent libpfm with more PMUs, that
>> means PAPI's PFM_PMU_MAX < actual PFM_PMU_MAX. That should not be a
>> problem. But the opposite is.
>> I agree that having the PFM_PMU_MAX in that enum as part of the ABI of
>> the library is not so good for compatibility. There is not much I can
>> do at this point to remove it. It is part of the ABI.  You cannot
>> easily remove it from the enum and provide a macro instead, as
>> suggested by Steve, because you may have user code doing: int
>> pmus[PFM_PMU_MAX]. I don't think compiler would accept a while loop in
>> there.
>>
>> I can certainly cleanup the internals of the library to not use
>> PFM_PMU_MAX and allocate dynamically and count the actual number of
>> entries on initialization. We could have the compiler generate a
>> warning whenever it sees PFM_PMU_MAX used. But that's probably about
>> it.
>>
>> Any other suggestions?
>>
>
> Hi Stephane,
>
> Yes, the description above is a decent summary of the issue.  What would like 
> to do is avoid that undesirable dependency on the build environment's 
> PFM_PMU_MAX. Just removing PFM_PMU_MAX from existing header file would cause 
> code to break and adding some variable in libpfm that contained the value of 
> PFM_PMU_MAX would cause an abi change to libpfm.
>
> As a workaround I made a proposed patch for PAPI that takes a closer look at 
> the error return codes of pfm_get_pmu_info.  If the return code is 
> PFM_ERR_NOTSUPP, it figures that there was actual pmu entry and continues 
> searching.  Is that a reasonable assumption on how pfm_get_pmu_info will work?

Looking at the current code, your assumption is correct. If the pmu
index is beyond PFM_PMU_MAX and everything is okay, then you will get
PFM_ERR_INVAL. You get PFM_ERR_NOTSUPP, if the PMU is implemented but
not detected on host hardware.

So you can use as a substitute to PFM_PMU_MAX to get the total number
of detected PMUs or total number of implemented PMUs (if you include
NOTSUPP).

As an extension, I can add a new entrypoint to return this info. That
would certainly be cleaner, though, it would not solve your problem
with existing releases.



>
> This patch is posted on 
> https://groups.google.com/a/icl.utk.edu/forum/#!topic/ptools-perfapi/Dx3xjwxplWo
>
> -Will

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] [PATCH] add power9 entries to validate_power.c

[Stephane Eranian via perfmon2-devel]

On Tue, Jun 6, 2017 at 9:09 AM, Will Schmidt 
wrote:

> Hi,
>
> Update the validate_power test to include power9 entries.
>
> Signed-off-by:  Will Schmidt 
>

Patch applied.
Thanks.


> --
>
> sniff-test run output:
> > ./validate
> Libpfm structure tests:
> libpfm ABI version : 0
> pfm_pmu_info_t : Passed
> pfm_event_info_t : Passed
> pfm_event_attr_info_t : Passed
> pfm_pmu_encode_arg_t : Passed
> pfm_perf_encode_arg_t : Passed
> Libpfm internal table tests:
> 
> checking power9 (946 events): Passed
> Architecture specific tests:
>  20 PowerPC events: 0 errors
> All tests passed
>
>
> diff --git a/tests/validate_power.c b/tests/validate_power.c
> index 74ab30c..617efca 100644
> --- a/tests/validate_power.c
> +++ b/tests/validate_power.c
> @@ -157,6 +157,20 @@ static const test_event_t ppc_test_events[]={
>   .codes[0] = 0xde200201e6ull,
>   .fstr = "power8::PM_RC_LIFETIME_EXC_32",
> },
> +   { SRC_LINE,
> + .name = "power9::PM_CYC",
> + .ret  = PFM_SUCCESS,
> + .count = 1,
> + .codes[0] = 0x1001e,
> + .fstr = "power9::PM_CYC",
> +   },
> +   { SRC_LINE,
> + .name = "power9::PM_INST_DISP",
> + .ret  = PFM_SUCCESS,
> + .count = 1,
> + .codes[0] = 0x200f2,
> + .fstr = "power9::PM_INST_DISP",
> +   },
>  { SRC_LINE,
>.name = "powerpc_nest_mcs_read::MCS_00",
>.ret = PFM_SUCCESS,
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] [PATCH] add power9 entries to validate_power.c

[Stephane Eranian via perfmon2-devel]

On Wed, Jun 14, 2017 at 5:57 AM, William Cohen  wrote:

> On 06/14/2017 08:47 AM, Stephane Eranian via perfmon2-devel wrote:
> >
> >
> > On Tue, Jun 6, 2017 at 9:09 AM, Will Schmidt  <mailto:will_schm...@vnet.ibm.com>> wrote:
> >
> > Hi,
> >
> > Update the validate_power test to include power9 entries.
> >
> > Signed-off-by:  Will Schmidt  will_schm...@vnet.ibm.com>>
> >
> >
> > Patch applied.
> > Thanks.
> >
>
> Hi Stephane,
>
> Have these patches been pushed to the upstream repo?  I didn't see
> anything.
>
> Did it just 30mn ago.


> -Will
> >
> > --
> >
> > sniff-test run output:
> > > ./validate
> > Libpfm structure tests:
> > libpfm ABI version : 0
> > pfm_pmu_info_t : Passed
> > pfm_event_info_t : Passed
> > pfm_event_attr_info_t : Passed
> > pfm_pmu_encode_arg_t : Passed
> > pfm_perf_encode_arg_t : Passed
> > Libpfm internal table tests:
> > 
> > checking power9 (946 events): Passed
> > Architecture specific tests:
> >  20 PowerPC events: 0 errors
> > All tests passed
> >
> >
> > diff --git a/tests/validate_power.c b/tests/validate_power.c
> > index 74ab30c..617efca 100644
> > --- a/tests/validate_power.c
> > +++ b/tests/validate_power.c
> > @@ -157,6 +157,20 @@ static const test_event_t ppc_test_events[]={
> >   .codes[0] = 0xde200201e6ull,
> >   .fstr = "power8::PM_RC_LIFETIME_EXC_32",
> > },
> > +   { SRC_LINE,
> > + .name = "power9::PM_CYC",
> > + .ret  = PFM_SUCCESS,
> > + .count = 1,
> > + .codes[0] = 0x1001e,
> > + .fstr = "power9::PM_CYC",
> > +   },
> > +   { SRC_LINE,
> > + .name = "power9::PM_INST_DISP",
> > + .ret  = PFM_SUCCESS,
> > + .count = 1,
> > + .codes[0] = 0x200f2,
> > + .fstr = "power9::PM_INST_DISP",
> > +   },
> >  { SRC_LINE,
> >.name = "powerpc_nest_mcs_read::MCS_00",
> >.ret = PFM_SUCCESS,
> >
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net <mailto:perfmon2-devel@lists.
> sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel <
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel>
> >
> >
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > ___
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 accepting invalid event umasks

[Stephane Eranian via perfmon2-devel]

Vince,

On Mon, Nov 13, 2017 at 12:02 PM, Vince Weaver 
wrote:

> Hello
>
> My student noticed that when she accidentally cut and pasted an invalid
> event it was being accepted as valid by libpfm4/PAPI.
>
> The event in question is two events stuck together with a comma.
> I think the second event is somehow being treated as an invalid umask and
> ignored.
>
> The event in this case is on Skylake:
>
> "DTLB_LOAD_MISSES:MISS_CAUSES_A_WALK,DTLB_STORE_MISSES:MISS_
> CAUSES_A_WALK:u=1"
>
> For example. running this:
> ./check_events  DTLB_LOAD_MISSES:MISS_CAUSES_
> A_WALK,DTLB_STORE_MISSES:MISS_CAUSES_A_WALK:u=1
>
> The issue here is that check_events does not take a comma separated list
of events, it takes a white space speratated list
of arguments.

The umask MISS_CAUSES_A_WALK is valid for the events here.


> Requested Event:
> DTLB_LOAD_MISSES:MISS_CAUSES_A_WALK,DTLB_STORE_MISSES:MISS_
> CAUSES_A_WALK:u=1
> ActualEvent: skl::DTLB_LOAD_MISSES:MISS_CAUSES_A_WALK:k=1:u=1:e=0:i=0:
> c=0:t=0:intx=0:intxcp=0
> PMU: Intel Skylake
> IDX: 419430412
> Codes  : 0x530108
>
> where it should probably return some sort of error?
>
> Vince
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 accepting invalid event umasks

[Stephane Eranian via perfmon2-devel]

On Mon, Nov 13, 2017 at 1:34 PM, Vince Weaver 
wrote:

> On Mon, 13 Nov 2017, Stephane Eranian wrote:
>
>
> > > The issue here is that check_events does not take a comma separated
> list
> > of events, it takes a white space speratated list
> > of arguments.
>
> yes.  The bug is that we weren't trying to query two events, we were just
> intending to do one but accidentally cut-and-pasted two events together
> like this.  We expected it would fail, but libpfm4 treats it as one valid
> event (both at the command line, and through the PAPI interface).
>
> > The umask MISS_CAUSES_A_WALK is valid for the events here.
>
> yes, but "MISS_CAUSES_A_WALK,DTLB_STORE_MISSES" is not, which is what I am
> picturing libpfm4 would be trying to match against.  I need to dig through
> the code and see what is happening.
>
> It does treat it as one event. It stops processing at the comma. You see
the actual event name
is correct.
It does not generate an error because it found a comma instead of \0.
We can fix that.


> > > Requested Event:
> > > DTLB_LOAD_MISSES:MISS_CAUSES_A_WALK,DTLB_STORE_MISSES:MISS_
> > > CAUSES_A_WALK:u=1
> > > ActualEvent: skl::DTLB_LOAD_MISSES:MISS_
> CAUSES_A_WALK:k=1:u=1:e=0:i=0:
> > > c=0:t=0:intx=0:intxcp=0
> > > PMU: Intel Skylake
> > > IDX: 419430412
> > > Codes  : 0x530108
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 accepting invalid event umasks

[Stephane Eranian via perfmon2-devel]

On Mon, Nov 13, 2017 at 6:36 PM, Stephane Eranian 
wrote:

>
>
> On Mon, Nov 13, 2017 at 1:34 PM, Vince Weaver 
> wrote:
>
>> On Mon, 13 Nov 2017, Stephane Eranian wrote:
>>
>>
>> > > The issue here is that check_events does not take a comma separated
>> list
>> > of events, it takes a white space speratated list
>> > of arguments.
>>
>> yes.  The bug is that we weren't trying to query two events, we were just
>> intending to do one but accidentally cut-and-pasted two events together
>> like this.  We expected it would fail, but libpfm4 treats it as one valid
>> event (both at the command line, and through the PAPI interface).
>>
>> > The umask MISS_CAUSES_A_WALK is valid for the events here.
>>
>> yes, but "MISS_CAUSES_A_WALK,DTLB_STORE_MISSES" is not, which is what I
>> am
>> picturing libpfm4 would be trying to match against.  I need to dig through
>> the code and see what is happening.
>>
>> It does treat it as one event. It stops processing at the comma. You see
> the actual event name
> is correct.
> It does not generate an error because it found a comma instead of \0.
> We can fix that.
>
>
Fixed upstream. Please pull and try again.


> > > Requested Event:
>> > > DTLB_LOAD_MISSES:MISS_CAUSES_A_WALK,DTLB_STORE_MISSES:MISS_
>> > > CAUSES_A_WALK:u=1
>> > > ActualEvent: skl::DTLB_LOAD_MISSES:MISS_CAU
>> SES_A_WALK:k=1:u=1:e=0:i=0:
>> > > c=0:t=0:intx=0:intxcp=0
>> > > PMU: Intel Skylake
>> > > IDX: 419430412
>> > > Codes  : 0x530108
>>
>>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] [PATCH] Ensure unique names for IBM Power 9 events

[Stephane Eranian via perfmon2-devel]

Will,

There is something I am missing here. You are creating _ALT version of
events with the same event code.
What's the point of that?
There should not be duplicate event names in any event tables. The
validation checks verify this.
On PPC, I understand that the event code is manually crafted and contains
more than an event code.
So are you saying that sometimes, you want to specify an evnet multiple
times, but to do so, you need
to use different event codes?
Please clarify.
Thanks.


On Mon, Dec 4, 2017 at 10:35 AM, William Cohen  wrote:

> Older versions of PAPI use the event name to look up the libpfm event
> number when doing the enumeration of the available events.  If there
> were multiple events with the same name in libpfm, the earliest one
> would be selected.  This selection would cause the enumeration of
> events in papi_native_avail to get stuck looping on the first
> duplicated named event in a pmu.  In the case of IBM Power 9 the
> enumeration would get stuck on PM_CO0_BUSY. Gave each event a unique
> name to avoid this unfortunate behavior.
> ---
>  lib/events/power9_events.h | 48 +++---
> 
>  1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/lib/events/power9_events.h b/lib/events/power9_events.h
> index d77bab3..f352ace 100644
> --- a/lib/events/power9_events.h
> +++ b/lib/events/power9_events.h
> @@ -1550,7 +1550,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "CO mach 0 Busy. Used by PMU to sample ave CO
> lifetime (mach0 used as sample point)",
>  },
>  [ POWER9_PME_PM_CO0_BUSY_ALT ] = {
> -   .pme_name = "PM_CO0_BUSY",
> +   .pme_name = "PM_CO0_BUSY_ALT",
> .pme_code = 0x04608C,
> .pme_short_desc = "CO mach 0 Busy.",
> .pme_long_desc = "CO mach 0 Busy. Used by PMU to sample ave CO
> lifetime (mach0 used as sample point)",
> @@ -2277,7 +2277,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "Data SLB Miss - Total of all segment sizes",
>  },
>  [ POWER9_PME_PM_DSLB_MISS_ALT ] = {
> -   .pme_name = "PM_DSLB_MISS",
> +   .pme_name = "PM_DSLB_MISS_ALT",
> .pme_code = 0x010016,
> .pme_short_desc = "gate_and(sd_pc_c0_comp_valid AND
> sd_pc_c0_comp_thread(0:1)=tid,sd_pc_c0_comp_ppc_count(0:3)) +
> gate_and(sd_pc_c1_comp_valid AND sd_pc_c1_comp_thread(0:1)=tid,
> sd_pc_c1_comp_ppc_count(0:3))",
> .pme_long_desc = "gate_and(sd_pc_c0_comp_valid AND
> sd_pc_c0_comp_thread(0:1)=tid,sd_pc_c0_comp_ppc_count(0:3)) +
> gate_and(sd_pc_c1_comp_valid AND sd_pc_c1_comp_thread(0:1)=tid,
> sd_pc_c1_comp_ppc_count(0:3))",
> @@ -3155,7 +3155,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "Instruction SLB Miss - Total of all segment
> sizes",
>  },
>  [ POWER9_PME_PM_ISLB_MISS_ALT ] = {
> -   .pme_name = "PM_ISLB_MISS",
> +   .pme_name = "PM_ISLB_MISS_ALT",
> .pme_code = 0x040006,
> .pme_short_desc = "Number of ISLB misses for this thread",
> .pme_long_desc = "Number of ISLB misses for this thread",
> @@ -3323,7 +3323,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "All successful I-side dispatches that were an L2
> miss for this thread (excludes i_l2mru_tch reqs)",
>  },
>  [ POWER9_PME_PM_L2_INST_MISS_ALT ] = {
> -   .pme_name = "PM_L2_INST_MISS",
> +   .pme_name = "PM_L2_INST_MISS_ALT",
> .pme_code = 0x04609E,
> .pme_short_desc = "All successful I-side dispatches that were an
> L2 miss for this thread (excludes i_l2mru_tch reqs)",
> .pme_long_desc = "All successful I-side dispatches that were an L2
> miss for this thread (excludes i_l2mru_tch reqs)",
> @@ -3335,7 +3335,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "All successful I-side dispatches for this thread
> (excludes i_l2mru_tch reqs)",
>  },
>  [ POWER9_PME_PM_L2_INST_ALT ] = {
> -   .pme_name = "PM_L2_INST",
> +   .pme_name = "PM_L2_INST_ALT",
> .pme_code = 0x03609E,
> .pme_short_desc = "All successful I-side dispatches for this
> thread (excludes i_l2mru_tch reqs)",
> .pme_long_desc = "All successful I-side dispatches for this thread
> (excludes i_l2mru_tch reqs)",
> @@ -3347,7 +3347,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "All successful D-side load dispatches for this
> thread (L2 miss + L2 hits)",
>  },
>  [ POWER9_PME_PM_L2_LD_DISP_ALT ] = {
> -   .pme_name = "PM_L2_LD_DISP",
> +   .pme_name = "PM_L2_LD_DISP_ALT",
> .pme_code = 0x036082,
> .pme_short_desc = "All successful I-or-D side load dispatches for
> this thread (excludes i_l2mru_tch_reqs)",
> .pme_long_desc = "All successful I-or-D side load dispatches for
> this thread (excludes i_l2mru_tch_reqs)",
> @@ -3359,7 +3359,7 @@ static const pme_power_entry_t power9_pe[] = {
> .pme_long_desc = "All successful D-side load d

Re: [perfmon2] [PATCH] Ensure unique names for IBM Power 9 events

[Stephane Eranian via perfmon2-devel]

On Tue, Dec 5, 2017 at 8:30 AM, Will Schmidt 
wrote:

> On Tue, 2017-12-05 at 10:00 -0500, William Cohen wrote:
> > On 12/05/2017 01:42 AM, Stephane Eranian wrote:
> > > Will,
> > >
> > > There is something I am missing here. You are creating _ALT version of
> events with the same event code.
> > > What's the point of that?
>
> The event codes should be unique.  The recent changes are mostly to add
> _ALTx to the names to ensure they are unique enough.
> More clarification below.
>
> > > There should not be duplicate event names in any event tables. The
> validation checks verify this.
> > > On PPC, I understand that the event code is manually crafted and
> contains more than an event code.
> > > So are you saying that sometimes, you want to specify an evnet
> multiple times, but to do so, you need
> > > to use different event codes?
> > > Please clarify.
> > > Thanks.
> >
> > Hi Stephane,
> >
> > I don't have the Power9 documentation (Will Schmidt, is there a public
> > version of power 9 docs available now?), so I don't know the
> >  details of the contraints on how different event can (and cannot) be
> > concurrently used.  There was some earlier discussion on the papi
> > mailing list about papi preset PAPI_L1_DCM being unusable on power9
> > because the PM_LD_MISS_L1 and PM_ST_MISS_L1 could not be used
> > concurrently on power9.  Power has some alternative codings for some
> > of the events that can be used instead to allow these metrics to be
> > gathered concurrently.  Those alternative encodings were added to
> > libpfm by:
> >
>
> At a high-ish level, for ppc64*, there are 4 counters on which events
> can be measured.   Events are usually only valid on one of the four
> counters. The leading 0x1 through 0x4 in the pme_code field tend
> to indicate which counter the event is valid on.
> If two events are both defined for the same counter, they won't work
> concurrently.
>
> Ok, I get that. But I am questioning the design choice here.
The same kind of constraints exists on X86. The kernel solves this
by multiplexing the event because it knows the event constraints/.

Here it appears the design choice was different. The kernel does not
know event constraints. They are encoded in the event code. Thus you
need to create events aliases where the counter index is different to
measure some events together and avoid multiplexing.

That means the users needs to be aware of potential aliases and pick
the right list of event names to make this work.

I get it now.

Thanks.


> So to make things better, a few of the often used events have alternates
> that utilize one or more of the other counters.
>
> So as example, looking at the LD and ST events (which is where we
> recently noticed this problem), after the _ALT naming fix went in:
> We were trying to run both the LD and ST event concurrently, and were
> failing, because both were defined for and trying to use counter #3.
> [ POWER9_PME_PM_LD_MISS_L1 ] = {
> .pme_name = "PM_LD_MISS_L1",
> .pme_code = 0x03E054,
> ^ counter #3
> [ POWER9_PME_PM_ST_MISS_L1 ] = {
> .pme_name = "PM_ST_MISS_L1",
> .pme_code = 0x0300F0,
> ^ counter #3
>
> So that 'fix' was to add the alternate event for the LD, which happens
> to be defined for counter #4.   And then to use that PM_LD_MISS_L1_ALT
> reference in place of PM_LD_MISS_L1 where we needed to.
>
> [ POWER9_PME_PM_LD_MISS_L1_ALT ] = {
> .pme_name = "PM_LD_MISS_L1_ALT",
> .pme_code = 0x0400F0,
> ^ counter #4
>
> There are a few recent changes flying around, which consist of:
>  1 - adding the alternate event to the table.
>  2 - making sure the pme_name reflects the _ALT name.
>
> I'll add, just to be clear, that the 'fixes' were mostly to fill in
> content that I had fumbled when initially building the table.  (We can't
> just swap out 3's for 4's, etc).  They should have been in place
> initially, it's simply something I missed when I did the initial
> generation of the tables.
>
> Thanks
> -Will (Schmidt)
>
>
> > commit ed3f51c4690685675cf2766edb90acbc0c1cdb67 (upstream/master,
> master)
> > Author: Will Schmidt 
> > Date:   Sun Dec 3 09:42:44 2017 -0800
> >
> > Add alternate event numbers for power9.
> >
> > I had previously missed adding the _ALT entries, which allow some
> > events to be specified on different counters. This patch fills
> > those in.
> >
> > This patch also adds a few validation tests for the ALT events.
> >
> > Signed-off-by: Will Schmidt  
> >
> > However, the above mentioned patch uses the same names multiple times
> once for the orginal event and another time for the alternative encoding.
> This made it impossible to select select the alternative events by name.
> The follow on patch makes the names unique. I took a look through the
> power9_events.h and this patch.  The event pme_codes are different between
> the normal and alt version of the events.
> >
> > -Will Cohen
> >
> > >
> > > On Mon, Dec 4, 201

[perfmon2] libpfm-4.9.0 released

[Stephane Eranian via perfmon2-devel]

Hello,

Happy New Year.

I have release version 4.9.0 for libpfm4.
This release contains many updates and support for new hardware.

Highlights:
 * Intel Broadwell EP uncore PMU (all boxes)
 * IBM Power9 core PMU support
 * Intel Skylake X core PMU support
 * AMD Fam17h (Zen) core PMU
 * AMD Fam16h (Jaguar) core PMU
 * many event table updates
 * many bug fixes
 * a new branch_smpl.c example
 * fixed rdpmc example
 * support for 38-bit raw umasks for Intel X86

Thanks to all the contributors.

I will make a new release as soon as I finish adding support for Skylake X
uncore PMU. It is already 70% complete now.

Thanks.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

[perfmon2] libpfm4 next release

[Stephane Eranian via perfmon2-devel]

Hi,


I will make a new release of libpfm4 this week given the amount of changes
since January.
If you have more updates that you would like to submit, now is the time.
Thanks.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 next release

[Stephane Eranian via perfmon2-devel]

Hi Andreas,

On Mon, Apr 23, 2018 at 12:25 PM, Andreas Beckmann  wrote:

> On 2018-04-23 19:26, Stephane Eranian via perfmon2-devel wrote:
> > I will make a new release of libpfm4 this week given the amount of
> changes
> > since January.
> > If you have more updates that you would like to submit, now is the time.
> > Thanks.
>
> Besides the typo/spacing patch I sent on the weekend, there are
> three more issues I noticed while packaging libpfm4 for Debian.
> The first should be trivial, the other two only affect port
> architectures and are not critical to be fixed.
>
> **
>
> Fix an event a with space in its name in lib/events/mips_74k_events.h:
> s/OCP_WRITE_CACHEABLE REQUESTS/OCP_WRITE_CACHEABLE_REQUESTS/
>
> Fixed.


> **
>
> On the sparc64 Debian port the build fails the validation test due to
> duplicate event definitions:
>
> ./tests/validate
> Libpfm structure tests:
> libpfm ABI version : 0
> pfm_pmu_info_t : Passed
> pfm_event_info_t : Passed
> pfm_event_attr_info_t : Passed
> pfm_pmu_encode_arg_t : Passed
> pfm_perf_encode_arg_t : Passed
> perf_events specific tests:
>  3 perf_events generic events: 0 errors
> Libpfm internal table tests:
> checking ultra12 (22 events): Passed
> checking ultra3 (65 events): pmu: ultra3 event12: Dispatch0_2nd_br
> code: 0x4 is duplicated in event24 : Dispatch0_rs_mispred
> Failed
> checking ultra3i (63 events): pmu: ultra3i event12:
> Dispatch0_2nd_br code: 0x4 is duplicated in event24 : Dispatch0_rs_mispred
> Failed
> checking ultra3p (71 events): pmu: ultra3p event12:
> Dispatch0_2nd_br code: 0x4 is duplicated in event24 : Dispatch0_rs_mispred
> Failed
> checking ultra4p (103 events): Passed
> checking niagara1 (9 events): Passed
> checking niagara2 (8 events): Passed
> checking perf (80 events): Passed
> checking perf_raw (1 events): Passed
> Architecture specific tests:
> Total 3 errors
>
> I get that too. But I cannot find the documentation anymore so  I cannot
fix these duplicates.


> Full log:
> https://buildd.debian.org/status/fetch.php?pkg=libpfm4&;
> arch=sparc64&ver=4.9.0%2Bgit21-gc4de2ea-1&stamp=1524399924&raw=0
>
> I do not have access to any sparc hardware to test something.
>
> **
>
> On the x32 Debian port the build fails the
>
> checking ix86arch (0 events): pmu: ix86arch :: no events
>

When I compiled with CC="gcc -m32" and run tests/validate, I get:
  checking ix86arch (7 events): Passed

Looking at the code, this maybe because you are testing on a processor that
predates Family 5, like earlier Pentium.

Failed
>
> This had worked in the past, so it may also depend on the hardware used
> for the buildd.
>
> Exactly, that's why I am asking about the processor model.


> Full log:
> https://buildd.debian.org/status/fetch.php?pkg=libpfm4&;
> arch=x32&ver=4.9.0%2Bgit21-gc4de2ea-1&stamp=1524396852&raw=0
> Old logs:
> https://buildd.debian.org/status/logs.php?pkg=libpfm4&arch=x32
>
> I could probably try debugging this in a chroot, but don't expect
> to have the time to do this.
>
> **
>
>
> Andreas
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 next release

[Stephane Eranian via perfmon2-devel]

Hi,

On Tue, May 8, 2018 at 11:01 AM, William Cohen  wrote:

> On 05/08/2018 01:42 PM, Walk, Steve wrote:
> >
> > Hi Vince,
> >
> >
> > It's my understanding that perfmon-libpfm4 has to be updated
> >
> > first on sourceforge.  I've had a merge request there since 03/20/18.
> >
> > Once it is merged there, I will submit the ThunderX2 changes to
> >
>

I cannot merge until I have a proof that the information used to build the
tables is publicly available somewhere.
So far no one has been able to point me to a web page or a PDF with the PMU
documentation.
Or we need a statement from Cavium authorizing the release of the event
table as build in the patch.



> > papi on bitbucket.
>
> Hi Steve,
>
> I wonder if it might have gotten lost or missed on:
>
> https://sourceforge.net/p/perfmon2/libpfm4/merge-requests/
>
> There are some other merges still open there.  It looks like some of those
> merge requests should also be closed as they are already merged in:
>
> s390/cpumf: add support for IBM z13/z13s counters
> s390/cpumf: check for counter facility availability
>
>
> See the Cavium ThunderX and ThunderX2:
> 8   openAdd Cavium ThunderX2/u/swalk-cavium/perfmon2/
>  Steve Walk  2018-03-20  2018-03-20
> 10  openAdd Cavium ThunderX /u/druizmu/perfmon2/Daniel
> Ruiz 2018-04-27  2018-04-27
>
> -Will
> >
> >
> > If this is not the expected workflow, please let me know.
> >
> >
> > We've had an internal version for a while and I think someone
> >
> > (Marketing? Sales?) has released it into the wild.  At least I've been
> >
> > getting customer questions.
> >
> >
> > I'd really like to get the changes deployed somewhere "official".
> >
> >
> > Regards,
> >
> >
> > Steve Walk
> >
> > Cavium
> >
> >
> > 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------
> 
> --
> > *From:* Vince Weaver 
> > *Sent:* Tuesday, May 8, 2018 11:33 AM
> > *To:* eran...@gmail.com
> > *Cc:* Stephane Eranian; perfmon2-devel
> > *Subject:* Re: [perfmon2] libpfm4 next release
> >
> > On Mon, 23 Apr 2018, Stephane Eranian via perfmon2-devel wrote:
> >
> >> I will make a new release of libpfm4 this week given the amount of
> changes
> >> since January.
> >> If you have more updates that you would like to submit, now is the time.
> >
> > is there any status on Cavium ThunderX (armv8) support?  We've had a
> > number of people asking for PAPI support for that, and I felt like at one
> > point some patches might have come across this list, but I can't seem to
> > find them right now.
> >
> > Vince
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > ___
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 next release

[Stephane Eranian via perfmon2-devel]

Hi Steve,

On Tue, May 8, 2018 at 6:17 PM, Walk, Steve  wrote:

> Hello Stephane,
>
>
> Ah, that explains the question I got last week.
>
>
> The bulk of the events in my patch are defined in the
>
> ARM Architecture Reference Manual,
>
> https://static.docs.arm.com/ddi0487/ca/DDI0487C_a_armv8_arm.pdf
>
> Section K3.1 ARM Recommendataions for IMPLEMENTATION
>
> DEFINED events, and  D5.10.3 Common Event Numbers.
>
>
> There are a few events that are ThunderX2 specific described in
>
> the Software Optimization Guide, but that document is available
>
> only through our support site.  At one point there was an NDA
>
> involved.  I don't know the document status since we announced
>
> GA yesterday.
>
>
> Can any of these document be accessed without a login now that the product
is GA?


> Of those few events, only one was used by PAPI.
>
>
> What kind of statement would you need from Cavium?
>
>
> A official statement stating that these PMU events are authorized for
public release and can be included
in open source code (which is using an MIT-based license).

Thanks.

Best Regards,
>
>
> Steve Walk
>
> Cavium
>
>
>
>
> --
> *From:* Stephane Eranian 
> *Sent:* Tuesday, May 8, 2018 3:55 PM
> *To:* William Cohen
> *Cc:* Walk, Steve; Vince Weaver; Jones, Joel; perfmon2-devel
> *Subject:* Re: [perfmon2] libpfm4 next release
>
> Hi,
>
> On Tue, May 8, 2018 at 11:01 AM, William Cohen  wrote:
>
> On 05/08/2018 01:42 PM, Walk, Steve wrote:
> >
> > Hi Vince,
> >
> >
> > It's my understanding that perfmon-libpfm4 has to be updated
> >
> > first on sourceforge.  I've had a merge request there since 03/20/18.
> >
> > Once it is merged there, I will submit the ThunderX2 changes to
> >
>
>
> I cannot merge until I have a proof that the information used to build the
> tables is publicly available somewhere.
> So far no one has been able to point me to a web page or a PDF with the
> PMU documentation.
> Or we need a statement from Cavium authorizing the release of the event
> table as build in the patch.
>
>
>
> > papi on bitbucket.
>
> Hi Steve,
>
> I wonder if it might have gotten lost or missed on:
>
> https://sourceforge.net/p/perfmon2/libpfm4/merge-requests/
>
> There are some other merges still open there.  It looks like some of those
> merge requests should also be closed as they are already merged in:
>
> s390/cpumf: add support for IBM z13/z13s counters
> s390/cpumf: check for counter facility availability
>
>
> See the Cavium ThunderX and ThunderX2:
> 8   openAdd Cavium ThunderX2/u/swalk-cavium/perfmon2/
>  Steve Walk  2018-03-20  2018-03-20
> 10  openAdd Cavium ThunderX /u/druizmu/perfmon2/Daniel
> Ruiz 2018-04-27  2018-04-27
>
> -Will
> >
> >
> > If this is not the expected workflow, please let me know.
> >
> >
> > We've had an internal version for a while and I think someone
> >
> > (Marketing? Sales?) has released it into the wild.  At least I've been
> >
> > getting customer questions.
> >
> >
> > I'd really like to get the changes deployed somewhere "official".
> >
> >
> > Regards,
> >
> >
> > Steve Walk
> >
> > Cavium
> >
> >
> > 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ----------------
> 
> 
> 
> 
> --
> > *From:* Vince Weaver 
> > *Sent:* Tuesday, May 8, 2018 11:33 AM
> > *To:* eran...@gmail.com
> > *Cc:* Stephane Eranian; per

Re: [perfmon2] libpfm4 next release

[Stephane Eranian via perfmon2-devel]

> 
> ------------
> 
> 
> 
> 
> 
> 
> --
> > *From:* Vince Weaver 
> > *Sent:* Tuesday, May 8, 2018 11:33 AM
> > *To:* eran...@gmail.com
> > *Cc:* Stephane Eranian; perfmon2-devel
> > *Subject:* Re: [perfmon2] libpfm4 next release
> >
> > On Mon, 23 Apr 2018, Stephane Eranian via perfmon2-devel wrote:
> >
> >> I will make a new release of libpfm4 this week given the amount of
> changes
> >> since January.
> >> If you have more updates that you would like to submit, now is the time.
> >
> > is there any status on Cavium ThunderX (armv8) support?  We've had a
> > number of people asking for PAPI support for that, and I felt like at one
> > point some patches might have come across this list, but I can't seem to
> > find them right now.
> >
> > Vince
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > ___
> > perfmon2-devel mailing list
> > perfmon2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> >
>
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] Understanding libpfm4 perf_events attribute translation

[Stephane Eranian via perfmon2-devel]

Hi,

On Tue, May 15, 2018 at 11:48 AM, laksono  wrote:

> All,
>
>
> I want to profile using MEM_TRANS_RETIRED::LATENCY_ABOVE_THRESHOLD
> counter on Intel SandyBridge. Using libpfm4's examples/check_event, I can
> extract the perf_events config into *0x5301cd* and *0x3* :
>
>
>  $ ./check_events snb::MEM_TRANS_RETIRED:LATENCY_ABOVE_THRESHOLD
>
>
> Requested Event: snb::MEM_TRANS_RETIRED:LATENCY_ABOVE_THRESHOLD
>
> ActualEvent: snb::MEM_TRANS_RETIRED:LATENCY
> _ABOVE_THRESHOLD:k=1:u=1:e=0:i=0:c=0:t=0:ldlat=3
>
> PMU: Intel Sandy Bridge
>
> IDX: 142606390
>
> Codes  : *0x5301cd* *0x3*
>
> However, looking at the result of examples/showevtinfo program, I believe
> the config number of MEM_TRANS_RETIRED::LATENCY_ABOVE_THRESHOLD should be
> *0x1cd* (*0x01* for the umask and *0xcd* for the code):
>
>
> IDX  : 142606390
>
> PMU name : snb (Intel Sandy Bridge)
>
> Name : MEM_TRANS_RETIRED
>
> Equiv: None
>
> Flags: [precise]
>
> Desc : Memory transactions retired
>
> Code : *0xcd*
>
> Umask-00 : *0x01* : PMU : [LATENCY_ABOVE_THRESHOLD] : [precise] : Memory
> load instructions retired above programmed clocks, minimum threshold value
> is 3 (Precise Event and ldlat required)
>
> Umask-01 : 0x02 : PMU : [PRECISE_STORE] : [precise] : Capture where stores
> occur, must use with PEBS (Precise Event required)
>
> Modif-00 : 0x00 : PMU : [k] : monitor at priv level 0 (boolean)
>
> Modif-01 : 0x01 : PMU : [u] : monitor at priv level 1, 2, 3 (boolean)
>
> Modif-02 : 0x02 : PMU : [e] : edge level (may require counter-mask >= 1)
> (boolean)
>
> Modif-03 : 0x03 : PMU : [i] : invert (boolean)
>
> Modif-04 : 0x04 : PMU : [c] : counter-mask in range [0-255] (integer)
>
> Modif-05 : 0x05 : PMU : [t] : measure any thread (boolean)
>
> Modif-06 : 0x06 : PMU : [ldlat] : load latency threshold (cycles,
> [3-65535]) (integer)
>
> The question is how pfm_get_os_event_encoding() translates
> MEM_TRANS_RETIRED::LATENCY_ABOVE_THRESHOLD into *0x5301cd* and *0x3*
> instead of *0x1cd* ?
>
> You can ignore the 0x5 in 0x5301cd, it is the enable bit which gets
overwriten by the kernel.
The case of 0x3 is more interesting. This event is special, it requires a
latency filter. As you see from the description, the event increments when
the load execution latency is above a certain threshold. Well, you need to
specify the threshold. This is done using the ldlat= modifier. If you don't
specify one, the library will assume you want to the smallest latency
possible which is 3.
Hope this clarifies how to use this event.


> Thanks
>
> Laksono Adhianto
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

[perfmon2] libpfm-4.10.0 released

[Stephane Eranian via perfmon2-devel]

Hello,

I have released version 4.10.0 of libpfm4.

This release contains support for new hardware as well has several bugs
fixes and improvements.
Highlights:
  - Intel Skylake X uncore PMUs support (all PMU boxes)
  - Cavium Thunder X2 support
  - Intel Knights Mill support (core and uncore)
  - s390 updates
  - several bug fixes
  - event table updates

Thanks to all the contributors.

You can get the new package from http://perfmon2.sf.net as usual.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

[perfmon2] libpfm-4.10.1 released

[Stephane Eranian via perfmon2-devel]

Hi,

I made a new minor release to fix the build issues of 4.10 on ARM.

It contains the following changes:
 - fix build issues with Cavium Thunder X2 on ARM 32 bit
 - update Intel Skylake event table

You can get the new package from http://perfmon2.sf.net as usual.
Thanks.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] ThunderX2 uncore events support

[Stephane Eranian via perfmon2-devel]

Will,

On Fri, Nov 1, 2019 at 12:01 PM Will Cohen  wrote:

> Hi Stephane,
>
> Would it be possible to get this patch for the Marvell ThunderX2 reviewed
> and merged into the upstream libpfm? -Will
>
> I can merge the patch if:
 - the uncore events are moved into their own
lib/event/cavium_x2_unc_eventt.h file to make this cleaner
 - I have a pointer to a public document describing these llc uncore events

thanks.


> On Thu, Oct 24, 2019 at 5:05 PM Shay Gal-On  wrote:
>
>> Hello,
>>
>>
>>
>> Uncore event support for Marvell ThunderX2 was added to Linux kernel
>> upstream, see https://lkml.org/lkml/2018/11/22/513
>>
>> Please see https://sourceforge.net/p/perfmon2/libpfm4/merge-requests/13/
>> to add support in libpfm.
>>
>>
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>>- Shay Gal-On
>>
>> Principal Engineer, Server Processor Business Unit, Marvell
>>
>>
>>
>>
>> ___
>> perfmon2-devel mailing list
>> perfmon2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>>
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] [EXT] Re: ThunderX2 uncore events support

[Stephane Eranian via perfmon2-devel]

Hi,

On Thu, Nov 21, 2019 at 10:50 AM Shay Gal-On  wrote:

> Hello,
>
> Finally got the event list published on the Marvell website at
> https://www.marvell.com/documents/hrur6mybdvk5uki1w0z7/
> Moved uncore events to separate header file and requested merge.
> Please let me know if there are any other changes required to merge this
> in.
>
> Ok, that should do it.
Thanks for your effort and understanding.


>
> Thanks,
>
> - Shay Gal-On
> -
> -Original Message-
> From: Shay Gal-On 
> Sent: Tuesday, November 12, 2019 2:31 PM
> To: William Cohen ; eran...@gmail.com
> Cc: perfmon2-devel@lists.sourceforge.net
> Subject: Re: [perfmon2] [EXT] Re: ThunderX2 uncore events support
>
> Done, working with corp red tape to get "official" doc updated with the
> uncore counter info.
>
> Thanks,
>
> - Shay Gal-On
> -
> -Original Message-
> From: William Cohen 
> Sent: Tuesday, November 12, 2019 12:46 PM
> To: Shay Gal-On ; eran...@gmail.com
> Cc: perfmon2-devel@lists.sourceforge.net
> Subject: Re: [EXT] Re: [perfmon2] ThunderX2 uncore events support
>
> On 11/4/19 12:46 PM, Shay Gal-On wrote:
> > Hello Stephane,
> >
> >
>
> Hi Shay,
>
> How is the patch rework coming to put the events in a separate header file?
>
> >
> > Does this count for docs?
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gpkulkarni_module-5Ftx2-5Fpmu_blob_master_thunderx2-2Devents.txt&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=qsCxaIqWOxCmR8DpNsh72r7QMpbYQOXOXh7_B3i2sH8&m=FMKgstDjTot45w8CtkbfmT7nkXu9vIW5KsyDfi7jLZk&s=GizVDoQuQM2xt9kQp-GmOJAqI_jI9CMFloeCfmAX5d4&e=
> >
> > If not, I can work with our legal to get something published through the
> Marvell support site.
>
> It would be wise to have something on a Marvell support site even if the
> github link above is good enough.
> >
> >
> >
> > Will move the event descriptions as requested.
> >
> > Is it ok if I call the file
> >
> > lib/event/marvell_thunderx2_uncore_events.h instead?
>
> Are there other uncore pmus on thunderx2 that might be exposed later?
> Would it be reasonable to name it lib/events/arm_tx2_unc_llc_events.h?
>
> -Will
> >
> >
> >
> > Thanks,
> >
> >
> >
> >   * Shay Gal-On
> >
> >
> >
> > *From:* Stephane Eranian 
> > *Sent:* Sunday, November 3, 2019 12:51 AM
> > *To:* Will Cohen 
> > *Cc:* Shay Gal-On ;
> perfmon2-devel@lists.sourceforge.net
> > *Subject:* [EXT] Re: [perfmon2] ThunderX2 uncore events support
> >
> >
> >
> > External Email
> >
> >
> --
> >
> > Will,
> >
> >
> >
> > On Fri, Nov 1, 2019 at 12:01 PM Will Cohen  wco...@redhat.com>> wrote:
> >
> > Hi Stephane,
> >
> >
> >
> > Would it be possible to get this patch for the Marvell ThunderX2
> reviewed and merged into the upstream libpfm? -Will
> >
> >
> >
> > I can merge the patch if:
> >
> >  - the uncore events are moved into their own
> lib/event/cavium_x2_unc_eventt.h file to make this cleaner
> >
> >  - I have a pointer to a public document describing these llc uncore
> events
> >
> >
> >
> > thanks.
> >
> >
> >
> > On Thu, Oct 24, 2019 at 5:05 PM Shay Gal-On  > wrote:
> >
> > Hello,
> >
> >
> >
> > Uncore event support for Marvell ThunderX2 was added to Linux
> kernel upstream, see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_11_22_513&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=qsCxaIqWOxCmR8DpNsh72r7QMpbYQOXOXh7_B3i2sH8&m=FMKgstDjTot45w8CtkbfmT7nkXu9vIW5KsyDfi7jLZk&s=9kVpHpzotXf09J9h9v3vsUZ7g0n6RpO60Ao4EuEgXFc&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_11_22_513&d=DwMFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=qsCxaIqWOxCmR8DpNsh72r7QMpbYQOXOXh7_B3i2sH8&m=_Ua7Ff4eypsMVn45rDcnRubawmnX5hlXhiiU3r-6MJE&s=BultQ4pTN6KaSmwr_KD012hHwZIN-zClnnuXT1D1kPA&e=
> >
> >
> > Please see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_perfmon2_libpfm4_merge-2Drequests_13_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=qsCxaIqWOxCmR8DpNsh72r7QMpbYQOXOXh7_B3i2sH8&m=FMKgstDjTot45w8CtkbfmT7nkXu9vIW5KsyDfi7jL

Re: [perfmon2] [EXT] Re: ThunderX2 uncore events support

[Stephane Eranian via perfmon2-devel]

Shay,

Looked at your patch. Why are you not providing the full list of DMC events.
The documentation shows 4 DMC events, but you encode only two. I understand
they are the most useful, but I think you need all of them, especially the
one counting
cycles in the DMC domain.

Same remark for the CCI PMU. Please add the cross-socket events. They are
useful.
I use the equivalent on Intel x86 all the time.

Also please add the Signed-off-by: signature on your patch.

Thanks.


On Thu, Nov 21, 2019 at 12:34 PM Stephane Eranian 
wrote:

> Hi,
>
> On Thu, Nov 21, 2019 at 10:50 AM Shay Gal-On  wrote:
>
>> Hello,
>>
>> Finally got the event list published on the Marvell website at
>> https://www.marvell.com/documents/hrur6mybdvk5uki1w0z7/
>> Moved uncore events to separate header file and requested merge.
>> Please let me know if there are any other changes required to merge this
>> in.
>>
>> Ok, that should do it.
> Thanks for your effort and understanding.
>
>
>>
>> Thanks,
>>
>> - Shay Gal-On
>> -
>> -Original Message-
>> From: Shay Gal-On 
>> Sent: Tuesday, November 12, 2019 2:31 PM
>> To: William Cohen ; eran...@gmail.com
>> Cc: perfmon2-devel@lists.sourceforge.net
>> Subject: Re: [perfmon2] [EXT] Re: ThunderX2 uncore events support
>>
>> Done, working with corp red tape to get "official" doc updated with the
>> uncore counter info.
>>
>> Thanks,
>>
>> - Shay Gal-On
>> -
>> -Original Message-
>> From: William Cohen 
>> Sent: Tuesday, November 12, 2019 12:46 PM
>> To: Shay Gal-On ; eran...@gmail.com
>> Cc: perfmon2-devel@lists.sourceforge.net
>> Subject: Re: [EXT] Re: [perfmon2] ThunderX2 uncore events support
>>
>> On 11/4/19 12:46 PM, Shay Gal-On wrote:
>> > Hello Stephane,
>> >
>> >
>>
>> Hi Shay,
>>
>> How is the patch rework coming to put the events in a separate header
>> file?
>>
>> >
>> > Does this count for docs?
>> >
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_gpkulkarni_module-5Ftx2-5Fpmu_blob_master_thunderx2-2Devents.txt&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=qsCxaIqWOxCmR8DpNsh72r7QMpbYQOXOXh7_B3i2sH8&m=FMKgstDjTot45w8CtkbfmT7nkXu9vIW5KsyDfi7jLZk&s=GizVDoQuQM2xt9kQp-GmOJAqI_jI9CMFloeCfmAX5d4&e=
>> >
>> > If not, I can work with our legal to get something published through
>> the Marvell support site.
>>
>> It would be wise to have something on a Marvell support site even if the
>> github link above is good enough.
>> >
>> >
>> >
>> > Will move the event descriptions as requested.
>> >
>> > Is it ok if I call the file
>> >
>> > lib/event/marvell_thunderx2_uncore_events.h instead?
>>
>> Are there other uncore pmus on thunderx2 that might be exposed later?
>> Would it be reasonable to name it lib/events/arm_tx2_unc_llc_events.h?
>>
>> -Will
>> >
>> >
>> >
>> > Thanks,
>> >
>> >
>> >
>> >   * Shay Gal-On
>> >
>> >
>> >
>> > *From:* Stephane Eranian 
>> > *Sent:* Sunday, November 3, 2019 12:51 AM
>> > *To:* Will Cohen 
>> > *Cc:* Shay Gal-On ;
>> perfmon2-devel@lists.sourceforge.net
>> > *Subject:* [EXT] Re: [perfmon2] ThunderX2 uncore events support
>> >
>> >
>> >
>> > External Email
>> >
>> >
>> --
>> >
>> > Will,
>> >
>> >
>> >
>> > On Fri, Nov 1, 2019 at 12:01 PM Will Cohen > wco...@redhat.com>> wrote:
>> >
>> > Hi Stephane,
>> >
>> >
>> >
>> > Would it be possible to get this patch for the Marvell ThunderX2
>> reviewed and merged into the upstream libpfm? -Will
>> >
>> >
>> >
>> > I can merge the patch if:
>> >
>> >  - the uncore events are moved into their own
>> lib/event/cavium_x2_unc_eventt.h file to make this cleaner
>> >
>> >  - I have a pointer to a public document describing these llc uncore
>> events
>> >
>> >
>> >
>> > thanks.
>> >
>> >
>> >
>> > On Thu, Oct 24, 2019 at 5:05 PM Shay Gal-On > > wrote:
>> >
>> > Hello,
>> >
>> >
>> >
>> > Uncore event support for Marvell ThunderX2 was added to Linux
>> kernel upstream, see
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2018_11_22_513&d=DwIGaQ&c=nKjWec2b6R

Re: [perfmon2] AMD fam17h floating point performance events

[Stephane Eranian via perfmon2-devel]

Hi,

On AMD Zen1 and Zen2 architectures, the event to count flops requires some
extra support as explained in the PPR.
But that extra support is needed in the kernel. AMD posted the patches
upstream and they are in 5.6 kernel.

The FLOPS event is one that can have large increments per cycle depending
on how wide the SIMDs are.
However, a single PMU counter can only take an increment/cycle of 15 or
less. FLOPS can exceed this limit.
To overcome this limitation, AMD implemented merging of counters. Two
consecutive counters are "fused" together
to make a counter capable of handling more than 15 increments/cycle.

As you can imagine given the way Linux perf_events works, this cannot be
transparent. Therefore, perf_events needs to be
patched to recognize that the FLOPS event is used and that perf_events
needs to allocate two consecutive counters and program the MERGE event
in the second counter to yield a valid FLOPS count. This is what AMD patche
(5738891229a perf/x86/amd: Add support for Large Increment per Cycle event).
This is all documented in the PPR under section 2.1.15.3.

Hope this helps.


On Thu, Apr 16, 2020 at 2:33 AM  wrote:

> Hi Vincent,
>
> Was this ever resolved? We appear to have the same issue
>
> Many thanks, Martyn
>
> On Friday, 31 August 2018 20:34:46 UTC+1, vincent.weaver wrote:
>>
>>
>> I was trying to work out why the PAPI floating point event validation
>> tests were failing on a Ryzen machine.
>>
>> PAPI is using:
>> 
>> RETIRED_SSE_AVX_OPERATIONS:DP_ADD_SUB_FLOPS:DP_MULT_FLOPS:DP_MULT_ADD_FLOPS:DP_DIV_FLOPS
>>
>> 0x53f003
>>
>> which I think should cover most double-precision floating point, and it
>> does record a lot of counts when run on Linpack.  However our simple
>> validation test does a matrix-matrix multiply that does
>>
>> mulsd  (%rax),%xmm0
>> addsd  %xmm0,%xmm1
>>
>> both of which I would think would count as SSE double-precision, but the
>> event doesn't incrememnt (the total count for the test ends up being 0).
>>
>> Expected results *are* returned if we use
>>
>> RETIRED_MMX_FP_INSTRUCTIONS:SSE_INSTR:MMX_INSTR:X87_INSTR
>> 0x5307cb
>> instead
>>
>> Does anyone know why this might be happening?
>>
>> Also, somewhat related, in reading the "Open Source Register Reference
>> for
>> AMD Family 17h" document it mentions the special "Merge" events for
>> combining results when the increment is too big.  Does libpfm4 support
>> this?  I suppose not as it doesn't appear that Linux supports this?
>>
>> Thanks,
>>
>> Vince
>>
>>
>>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

[perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

Hello,

After more than 2 years without a release, I decided it was way overdue! I
am hoping to get back to a more regular release schedule past 2020. But the
development never actually stopped, so everything was already available in
the git repository.

Lots of new support in this release:
  - Intel Icelake core PMU
  - AMD Zen2 core PMU
  - AMD Zen1 core PMU
  - ARM Neoverse N1 core PMU
  - Intel CascadelakeX uncore PMU
  - IBM s390 updates
  - lot of Intel event table updates
  - Intel Tremont core PMU support
  - Intel RAPL updates
  - Marvell TX2 core and uncore support
  - enhanced per-event info: can report if event is speculative (starting
with Intel Icelake)
  - support for Intel Icelake Extended PEBS via hw_smple attribute
  - rtop examples building conditionally now (must have ncurses-devel)
  - many bug fixes

Thanks to all the contributors.
Release is available here

.

Enjoy!
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

On Tue, Sep 8, 2020 at 8:27 AM William Cohen  wrote:

> On 9/7/20 6:03 PM, Stephane Eranian via perfmon2-devel wrote:
> > Hello,
> >
> > After more than 2 years without a release, I decided it was way overdue!
> I am hoping to get back to a more regular release schedule past 2020. But
> the development never actually stopped, so everything was already
> available in the git repository.
> >
> > Lots of new support in this release:
> >   - Intel Icelake core PMU
> >   - AMD Zen2 core PMU
> >   - AMD Zen1 core PMU
> >   - ARM Neoverse N1 core PMU
> >   - Intel CascadelakeX uncore PMU
> >   - IBM s390 updates
> >   - lot of Intel event table updates
> >   - Intel Tremont core PMU support
> >   - Intel RAPL updates
> >   - Marvell TX2 core and uncore support
> >   - enhanced per-event info: can report if event is speculative
> (starting with Intel Icelake)
> >   - support for Intel Icelake Extended PEBS via hw_smple attribute
> >   - rtop examples building conditionally now (must have ncurses-devel)
> >   - many bug fixes
> >
> > Thanks to all the contributors.
> > Release is available here <
> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
> >.
> >
> > Enjoy!
>
> Hi Stephane,
>
> Thanks very much for the new libpfm release.  I have created a build of it
> in Fedora Rawhide, libpfm-4.11.0-1.fc34 :
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=51008386
>
> I see there is also Fujitsu A64FX support in there.  However, the
> documentation page is only installed for the 32-bit arm
> (CONFIG_PFMLIB_ARCH_ARM).  It doesn't get included in the
> CONFIG_PFMLIB_ARCH_ARM64 build.
>
> I will fix that this week.
Let me know if you found anything else.
Thanks.
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

On Wed, Sep 23, 2020 at 7:32 AM William Cohen  wrote:

> On 9/10/20 7:32 PM, Stephane Eranian wrote:
> >
> >
> > On Tue, Sep 8, 2020 at 8:27 AM William Cohen  wco...@redhat.com>> wrote:
> >
> >     On 9/7/20 6:03 PM, Stephane Eranian via perfmon2-devel wrote:
> > > Hello,
> > >
> > > After more than 2 years without a release, I decided it was way
> overdue! I am hoping to get back to a more regular release schedule past
> 2020. But the development never actually stopped, so everything was already
> available in the git repository.
> > >
> > > Lots of new support in this release:
> > >   - Intel Icelake core PMU
> > >   - AMD Zen2 core PMU
> > >   - AMD Zen1 core PMU
> > >   - ARM Neoverse N1 core PMU
> > >   - Intel CascadelakeX uncore PMU
> > >   - IBM s390 updates
> > >   - lot of Intel event table updates
> > >   - Intel Tremont core PMU support
> > >   - Intel RAPL updates
> > >   - Marvell TX2 core and uncore support
> > >   - enhanced per-event info: can report if event is speculative
> (starting with Intel Icelake)
> > >   - support for Intel Icelake Extended PEBS via hw_smple attribute
> > >   - rtop examples building conditionally now (must have
> ncurses-devel)
> > >   - many bug fixes
> > >
> > > Thanks to all the contributors.
> > > Release is available here <
> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
> >.
> > >
> > > Enjoy!
> >
> > Hi Stephane,
> >
> > Thanks very much for the new libpfm release.  I have created a build
> of it in Fedora Rawhide, libpfm-4.11.0-1.fc34 :
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=51008386
> >
> > I see there is also Fujitsu A64FX support in there.  However, the
> documentation page is only installed for the 32-bit arm
> (CONFIG_PFMLIB_ARCH_ARM).  It doesn't get included in the
> CONFIG_PFMLIB_ARCH_ARM64 build.
> >
> > I will fix that this week.
> > Let me know if you found anything else.
> > Thanks.
> >
>
> Hi Stephane,
>
> I noticed that the libpfm library generated by libpfm-4.11.0 is:
>
>  /usr/lib64/libpfm.so.4.10.1
>
> It looks like the this is due to the following not being bumped in the
> release:
>
> config.mk:REVISION=10
>
> I don't see this this in my tree.
Did you upgrade to the latest?


> -Will
>
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

On Wed, Sep 23, 2020 at 4:08 PM William Cohen  wrote:

> On 9/23/20 6:31 PM, Stephane Eranian wrote:
> >
> >
> > On Wed, Sep 23, 2020 at 7:32 AM William Cohen  <mailto:wco...@redhat.com>> wrote:
> >
> > On 9/10/20 7:32 PM, Stephane Eranian wrote:
> > >
> > >
> > > On Tue, Sep 8, 2020 at 8:27 AM William Cohen  <mailto:wco...@redhat.com> <mailto:wco...@redhat.com  wco...@redhat.com>>> wrote:
> > >
> > > On 9/7/20 6:03 PM, Stephane Eranian via perfmon2-devel wrote:
> > > > Hello,
> > > >
> > > > After more than 2 years without a release, I decided it was
> way overdue! I am hoping to get back to a more regular release schedule
> past 2020. But the development never actually stopped, so everything was
> already available in the git repository.
> > > >
> > > > Lots of new support in this release:
> > > >   - Intel Icelake core PMU
> > > >   - AMD Zen2 core PMU
> > > >   - AMD Zen1 core PMU
> > > >   - ARM Neoverse N1 core PMU
> > > >   - Intel CascadelakeX uncore PMU
> > > >   - IBM s390 updates
> > > >   - lot of Intel event table updates
> > > >   - Intel Tremont core PMU support
> > > >   - Intel RAPL updates
> > > >   - Marvell TX2 core and uncore support
> > > >   - enhanced per-event info: can report if event is
> speculative (starting with Intel Icelake)
> > > >   - support for Intel Icelake Extended PEBS via hw_smple
> attribute
> > > >   - rtop examples building conditionally now (must have
> ncurses-devel)
> > > >   - many bug fixes
> > > >
> > > > Thanks to all the contributors.
> > > > Release is available here <
> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
> >.
> > > >
> > > > Enjoy!
> > >
> > > Hi Stephane,
> > >
> > > Thanks very much for the new libpfm release.  I have created a
> build of it in Fedora Rawhide, libpfm-4.11.0-1.fc34 :
> > >
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=51008386
> > >
> > > I see there is also Fujitsu A64FX support in there.  However,
> the documentation page is only installed for the 32-bit arm
> (CONFIG_PFMLIB_ARCH_ARM).  It doesn't get included in the
> CONFIG_PFMLIB_ARCH_ARM64 build.
> > >
> > > I will fix that this week.
> > > Let me know if you found anything else.
> > > Thanks.
> > >
> >
> > Hi Stephane,
> >
> > I noticed that the libpfm library generated by libpfm-4.11.0 is:
> >
> >  /usr/lib64/libpfm.so.4.10.1
> >
> > It looks like the this is due to the following not being bumped in
> the release:
> >
> > config.mk:REVISION=10
>
> Hi,
>
> This was observed in the upstream config.mk. This can be seen in line 113
> of:
>
> https://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/config.mk
>
> Got it.
I had one commit not pushed. Should be fixed now.
Thanks.


> -Will
>
> >
> > I don't see this this in my tree.
> > Did you upgrade to the latest?
> >
> >
> > -Will
> >
>
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

On Wed, Sep 23, 2020 at 4:26 PM William Cohen  wrote:

> On 9/23/20 7:09 PM, Stephane Eranian wrote:
> >
> >
> > On Wed, Sep 23, 2020 at 4:08 PM William Cohen  <mailto:wco...@redhat.com>> wrote:
> >
> > On 9/23/20 6:31 PM, Stephane Eranian wrote:
> > >
> > >
> > > On Wed, Sep 23, 2020 at 7:32 AM William Cohen  <mailto:wco...@redhat.com> <mailto:wco...@redhat.com  wco...@redhat.com>>> wrote:
> > >
> > > On 9/10/20 7:32 PM, Stephane Eranian wrote:
> > > >
> > > >
> > > > On Tue, Sep 8, 2020 at 8:27 AM William Cohen <
> wco...@redhat.com <mailto:wco...@redhat.com> <mailto:wco...@redhat.com
> <mailto:wco...@redhat.com>> <mailto:wco...@redhat.com  wco...@redhat.com> <mailto:wco...@redhat.com <mailto:wco...@redhat.com>>>>
> wrote:
> > > >
> > > > On 9/7/20 6:03 PM, Stephane Eranian via perfmon2-devel
> wrote:
> > > > > Hello,
> > > > >
> > > > > After more than 2 years without a release, I decided
> it was way overdue! I am hoping to get back to a more regular
> release schedule past 2020. But the development never actually stopped, so
> everything was already available in the git repository.
> > > > >
> > > > > Lots of new support in this release:
> > > > >   - Intel Icelake core PMU
> > > > >   - AMD Zen2 core PMU
> > > > >   - AMD Zen1 core PMU
> > > > >   - ARM Neoverse N1 core PMU
> > > > >   - Intel CascadelakeX uncore PMU
> > > > >   - IBM s390 updates
> > > > >   - lot of Intel event table updates
> > > > >   - Intel Tremont core PMU support
> > > > >   - Intel RAPL updates
> > > > >   - Marvell TX2 core and uncore support
> > > > >   - enhanced per-event info: can report if event is
> speculative (starting with Intel Icelake)
> > > > >   - support for Intel Icelake Extended PEBS via
> hw_smple attribute
> > > > >   - rtop examples building conditionally now (must
> have ncurses-devel)
> > > > >   - many bug fixes
> > > > >
> > > > > Thanks to all the contributors.
> > > > > Release is available here <
> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
> >.
> > > > >
> > > > > Enjoy!
> > > >
> > > > Hi Stephane,
> > > >
> > > > Thanks very much for the new libpfm release.  I have
> created a build of it in Fedora Rawhide, libpfm-4.11.0-1.fc34 :
> > > >
> > > >
> https://koji.fedoraproject.org/koji/taskinfo?taskID=51008386
> > > >
> > > > I see there is also Fujitsu A64FX support in there.
> However, the documentation page is only installed for the 32-bit arm
> (CONFIG_PFMLIB_ARCH_ARM).  It doesn't get included in the
> CONFIG_PFMLIB_ARCH_ARM64 build.
> > > >
> > > > I will fix that this week.
> > > > Let me know if you found anything else.
> > > > Thanks.
> > > >
> > >
> > > Hi Stephane,
> > >
> > > I noticed that the libpfm library generated by libpfm-4.11.0
> is:
> > >
> > >  /usr/lib64/libpfm.so.4.10.1
> > >
> > > It looks like the this is due to the following not being
> bumped in the release:
> > >
> > > config.mk:REVISION=10
> >
> > Hi,
> >
> > This was observed in the upstream config.mk <http://config.mk>.
> This can be seen in line 113 of:
> >
> > https://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/config.mk
> >
> > Got it.
> > I had one commit not pushed. Should be fixed now.
> > Thanks.
>
> Hi,
>
> Doesn't a new tarball need to be created for libpfm-4.11.0.tar.gz?  The
> current one at
> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
> has the wrong shared library version.  Building the rawhide libpfm rpm that
> uses that tarball was where I initially noticed the shared library
> versioning issue.
>
> Yes, I will push a new tarball and a minor revision once I fix the other
problem you mentioned.


> -Will
>
> >
> >
> > -Will
> >
> > >
> > > I don't see this this in my tree.
> > > Did you upgrade to the latest?
> > >
> > >
> > > -Will
> > >
> >
>
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

Will,

Can you test that the current git tree has all the bugs  you reported fixed?
Thanks.



On Wed, Sep 23, 2020 at 4:52 PM Stephane Eranian 
wrote:

>
>
> On Wed, Sep 23, 2020 at 4:26 PM William Cohen  wrote:
>
>> On 9/23/20 7:09 PM, Stephane Eranian wrote:
>> >
>> >
>> > On Wed, Sep 23, 2020 at 4:08 PM William Cohen > <mailto:wco...@redhat.com>> wrote:
>> >
>> > On 9/23/20 6:31 PM, Stephane Eranian wrote:
>> > >
>> > >
>> > > On Wed, Sep 23, 2020 at 7:32 AM William Cohen > <mailto:wco...@redhat.com> <mailto:wco...@redhat.com > wco...@redhat.com>>> wrote:
>> > >
>> > > On 9/10/20 7:32 PM, Stephane Eranian wrote:
>> > > >
>> > > >
>> > > > On Tue, Sep 8, 2020 at 8:27 AM William Cohen <
>> wco...@redhat.com <mailto:wco...@redhat.com> <mailto:wco...@redhat.com
>> <mailto:wco...@redhat.com>> <mailto:wco...@redhat.com > wco...@redhat.com> <mailto:wco...@redhat.com <mailto:wco...@redhat.com>>>>
>> wrote:
>> > > >
>> > > > On 9/7/20 6:03 PM, Stephane Eranian via perfmon2-devel
>> wrote:
>> > > > > Hello,
>> > > > >
>> > > > > After more than 2 years without a release, I decided
>> it was way overdue! I am hoping to get back to a more regular
>> release schedule past 2020. But the development never actually stopped, so
>> everything was already available in the git repository.
>> > > > >
>> > > > > Lots of new support in this release:
>> > > > >   - Intel Icelake core PMU
>> > > > >   - AMD Zen2 core PMU
>> > > > >   - AMD Zen1 core PMU
>> > > > >   - ARM Neoverse N1 core PMU
>> > > > >   - Intel CascadelakeX uncore PMU
>> > > > >   - IBM s390 updates
>> > > > >   - lot of Intel event table updates
>> > > > >   - Intel Tremont core PMU support
>> > > > >   - Intel RAPL updates
>> > > > >   - Marvell TX2 core and uncore support
>> > > > >   - enhanced per-event info: can report if event is
>> speculative (starting with Intel Icelake)
>> > > > >   - support for Intel Icelake Extended PEBS via
>> hw_smple attribute
>> > > > >   - rtop examples building conditionally now (must
>> have ncurses-devel)
>> > > > >   - many bug fixes
>> > > > >
>> > > > > Thanks to all the contributors.
>> > > > > Release is available here <
>> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
>> >.
>> > > > >
>> > > > > Enjoy!
>> > > >
>> > > > Hi Stephane,
>> > > >
>> > > > Thanks very much for the new libpfm release.  I have
>> created a build of it in Fedora Rawhide, libpfm-4.11.0-1.fc34 :
>> > > >
>> > > >
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=51008386
>> > > >
>> > > > I see there is also Fujitsu A64FX support in there.
>> However, the documentation page is only installed for the 32-bit arm
>> (CONFIG_PFMLIB_ARCH_ARM).  It doesn't get included in the
>> CONFIG_PFMLIB_ARCH_ARM64 build.
>> > > >
>> > > > I will fix that this week.
>> > > > Let me know if you found anything else.
>> > > > Thanks.
>> > > >
>> > >
>> > > Hi Stephane,
>> > >
>> > > I noticed that the libpfm library generated by libpfm-4.11.0
>> is:
>> > >
>> > >  /usr/lib64/libpfm.so.4.10.1
>> > >
>> > > It looks like the this is due to the following not being
>> bumped in the release:
>> > >
>> > > config.mk:REVISION=10
>> >
>> > Hi,
>> >
>> > This was observed in the upstream config.mk <http://config.mk>.
>> This can be seen in line 113 of:
>> >
>> > https://sourceforge.net/p/perfmon2/libpfm4/ci/master/tree/config.mk
>> >
>> > Got it.
>> > I had one commit not pushed. Should be fixed now.
>> > Thanks.
>>
>> Hi,
>>
>> Doesn't a new tarball need to be created for libpfm-4.11.0.tar.gz?  The
>> current one at
>> https://sourceforge.net/projects/perfmon2/files/libpfm4/libpfm-4.11.0.tar.gz/download
>> has the wrong shared library version.  Building the rawhide libpfm rpm that
>> uses that tarball was where I initially noticed the shared library
>> versioning issue.
>>
>> Yes, I will push a new tarball and a minor revision once I fix the other
> problem you mentioned.
>
>
>> -Will
>>
>> >
>> >
>> > -Will
>> >
>> > >
>> > > I don't see this this in my tree.
>> > > Did you upgrade to the latest?
>> > >
>> > >
>> > > -Will
>> > >
>> >
>>
>>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

On Thu, Sep 24, 2020 at 5:31 PM Andreas Beckmann  wrote:

> On 9/24/20 11:10 PM, Stephane Eranian via perfmon2-devel wrote:
> > Will,
> >
> > Can you test that the current git tree has all the bugs  you reported
> fixed?
> > Thanks.
>
> I have attached two more patches (typos and strncpy usage) from the
> Debian packaging.
>
>
> Patches applied.
Thanks for contributing.


> Andreas
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm-4.11.0 released

[Stephane Eranian via perfmon2-devel]

On Sat, Sep 26, 2020 at 7:51 PM William Cohen  wrote:

> On 9/24/20 5:10 PM, Stephane Eranian wrote:
> > Will,
> >
> > Can you test that the current git tree has all the bugs  you reported
> fixed?
> > Thanks.
> >
> >
>
> Hi,
>
> I generated a tarball with:
>
> git archive --prefix=libpfm-4.11.1/ --format=tar |gzip >
> libpfm-4.11.1.tar.gz
>
> Tweaked the libpfm.spec file to use that new tar file and did a scratch
> build for Fedora rawhide:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=52331671
>
> The a64fx man page is in the aarch64
> $ rpm -qs /home/wcohen/Downloads/libpfm-devel-4.11.1-1.fc34git.aarch64.rpm
> |grep a64fx
> (no state)/usr/share/man/man3/libpfm_arm_a64fx.3.gz
>
> The shared library versioning looks correct now:
>
> $ ls -l /usr/lib64/libpfm*
> -rw-r--r--. 1 root root 3807130 Sep 26 22:29 /usr/lib64/libpfm.a
> lrwxrwxrwx. 1 root root  16 Sep 26 22:29 /usr/lib64/libpfm.so ->
> libpfm.so.4.11.1
> lrwxrwxrwx. 1 root root  16 Sep 26 22:29 /usr/lib64/libpfm.so.4 ->
> libpfm.so.4.11.1
> -rwxr-xr-x. 1 root root 2602848 Sep 26 22:29 /usr/lib64/libpfm.so.4.11.1
>
> Looks good. Thanks for testing.
Given that I made further updates, I will push a 4.11.2 release instead.


> Thanks,
>
> -Will
>
> >
> > On Wed, Sep 23, 2020 at 4:52 PM Stephane Eranian  <mailto:eran...@googlemail.com>> wrote:
> >
> >
> >
> > On Wed, Sep 23, 2020 at 4:26 PM William Cohen  <mailto:wco...@redhat.com>> wrote:
> >
> > On 9/23/20 7:09 PM, Stephane Eranian wrote:
> > >
> > >
> > > On Wed, Sep 23, 2020 at 4:08 PM William Cohen <
> wco...@redhat.com <mailto:wco...@redhat.com> <mailto:wco...@redhat.com
> <mailto:wco...@redhat.com>>> wrote:
> > >
> > > On 9/23/20 6:31 PM, Stephane Eranian wrote:
> > > >
> > > >
> > > > On Wed, Sep 23, 2020 at 7:32 AM William Cohen <
> wco...@redhat.com <mailto:wco...@redhat.com> <mailto:wco...@redhat.com
> <mailto:wco...@redhat.com>> <mailto:wco...@redhat.com  wco...@redhat.com> <mailto:wco...@redhat.com <mailto:wco...@redhat.com>>>>
> wrote:
> > > >
> > > > On 9/10/20 7:32 PM, Stephane Eranian wrote:
> > > > >
> > > > >
> > > > > On Tue, Sep 8, 2020 at 8:27 AM William Cohen <
> wco...@redhat.com <mailto:wco...@redhat.com> <mailto:wco...@redhat.com
> <mailto:wco...@redhat.com>> <mailto:wco...@redhat.com  wco...@redhat.com> <mailto:wco...@redhat.com <mailto:wco...@redhat.com>>>
> <mailto:wco...@redhat.com <mailto:wco...@redhat.com>  wco...@redhat.com <mailto:wco...@redhat.com>> <mailto:wco...@redhat.com
> <mailto:wco...@redhat.com> <mailto:wco...@redhat.com  wco...@redhat.com>>>>> wrote:
> > > > >
> > > > > On 9/7/20 6:03 PM, Stephane Eranian via
> perfmon2-devel wrote:
> > > > > > Hello,
> > > > > >
> > > > > > After more than 2 years without a release, I
> decided it was way overdue! I am hoping to get back to a more regular
> release schedule past 2020. But the development never actually stopped, so
> everything was already available in the git repository.
> > > > > >
> > > > > > Lots of new support in this release:
> > > > > >   - Intel Icelake core PMU
> > > > > >   - AMD Zen2 core PMU
> > > > > >   - AMD Zen1 core PMU
> > > > > >   - ARM Neoverse N1 core PMU
> > > > > >   - Intel CascadelakeX uncore PMU
> > > > > >   - IBM s390 updates
> > > > > >   - lot of Intel event table updates
> > > > > >   - Intel Tremont core PMU support
> > > > > >   - Intel RAPL updates
> > > > > >   - Marvell TX2 core and uncore support
> > > > > >   - enhanced per-event info: can report if
> event is speculative (starting with Intel Icelake)
> > > > > >   

Re: [perfmon2] libpfm4 Zen2 support

[Stephane Eranian via perfmon2-devel]

Hi Vince,

Confirmed and fixed.
Thanks for tracking it down.


On Mon, May 24, 2021 at 1:26 PM Vince Weaver 
wrote:

>
> In PAPI we were having people with Zen2 machines being detected as Zen1.
>
> From what I can tell, Zen1 and Zen+ have model numbers less than 0x30
> and Zen2 is above 0x30.  This is what the perf tool uses for the cutoff
> too.
>
> Signed-off-by: Vince Weaver 
>
> diff --git a/lib/pfmlib_amd64.c b/lib/pfmlib_amd64.c
> index c4497ea..a3eb5d8 100644
> --- a/lib/pfmlib_amd64.c
> +++ b/lib/pfmlib_amd64.c
> @@ -174,11 +174,10 @@ amd64_get_revision(pfm_amd64_config_t *cfg)
> } else if (cfg->family == 21) { /* family 15h */
> rev = PFM_PMU_AMD64_FAM15H_INTERLAGOS;
> } else if (cfg->family == 23) { /* family 17h */
> -switch (cfg->model) {
> -case 49:
> +   if (cfg->model>=48) {
> rev = PFM_PMU_AMD64_FAM17H_ZEN2;
> -   break;
> -default:
> +   }
> +   else {
>  rev = PFM_PMU_AMD64_FAM17H_ZEN1;
>  }
> } else if (cfg->family == 22) { /* family 16h */
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 on GCC 12: pfmlib_perf_event_pmu.c:293:47: error: pointer may be used after 'realloc'

[Stephane Eranian via perfmon2-devel]

Hi,

Thanks for the report,

I will fix this in the coming days.

On Sat, Jun 4, 2022 at 10:08 AM Vitaly Chikunov  wrote:
>
> Stephane,
>
> There is compile failure on GCC 12.1.1:
>
>   pfmlib_perf_event_pmu.c: In function 'perf_table_alloc_event':
>   pfmlib_perf_event_pmu.c:293:47: error: pointer may be used after 'realloc' 
> [-Werror=use-after-free]
> 293 | perf_pe_free = new_pe + (perf_pe_free - perf_pe);
> |   ^
>   pfmlib_perf_event_pmu.c:289:18: note: call to 'realloc' here
> 289 | new_pe = realloc(perf_pe, perf_pe_count * 
> sizeof(perf_event_t));
> |  
> ^~
>   In function 'perf_table_alloc_umask',
>   inlined from 'gen_tracepoint_table' at pfmlib_perf_event_pmu.c:457:10:
>   pfmlib_perf_event_pmu.c:329:47: error: pointer may be used after 'realloc' 
> [-Werror=use-after-free]
> 329 | perf_um_free = new_um + (perf_um_free - perf_um);
> |   ^
>   pfmlib_perf_event_pmu.c:325:18: note: call to 'realloc' here
> 325 | new_um = realloc(perf_um, perf_um_count * sizeof(*new_um));
> |  ^
>   cc1: all warnings being treated as errors
>
> Also, pointer arithmetic on unallocated region are, perhaps, undefined
> behavior by C standard. So even though this math looks safe on x86 this
> should be fixed anyway to be more portable.
>
> Thanks,
>


___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 on GCC 12: pfmlib_perf_event_pmu.c:293:47: error: pointer may be used after 'realloc'

[Stephane Eranian via perfmon2-devel]

Hi,

Could you try the attached patch?
There is no use after free in the code as far as I can tell.
But I modified the code to avoid triggering the gcc warning.
I don't have gcc-12 so let me know if this works for you.


On Tue, Jun 7, 2022 at 1:26 AM Stephane Eranian  wrote:
>
> Hi,
>
> Thanks for the report,
>
> I will fix this in the coming days.
>
> On Sat, Jun 4, 2022 at 10:08 AM Vitaly Chikunov  wrote:
> >
> > Stephane,
> >
> > There is compile failure on GCC 12.1.1:
> >
> >   pfmlib_perf_event_pmu.c: In function 'perf_table_alloc_event':
> >   pfmlib_perf_event_pmu.c:293:47: error: pointer may be used after 
> > 'realloc' [-Werror=use-after-free]
> > 293 | perf_pe_free = new_pe + (perf_pe_free - perf_pe);
> > |   ^
> >   pfmlib_perf_event_pmu.c:289:18: note: call to 'realloc' here
> > 289 | new_pe = realloc(perf_pe, perf_pe_count * 
> > sizeof(perf_event_t));
> > |  
> > ^~
> >   In function 'perf_table_alloc_umask',
> >   inlined from 'gen_tracepoint_table' at pfmlib_perf_event_pmu.c:457:10:
> >   pfmlib_perf_event_pmu.c:329:47: error: pointer may be used after 
> > 'realloc' [-Werror=use-after-free]
> > 329 | perf_um_free = new_um + (perf_um_free - perf_um);
> > |   ^
> >   pfmlib_perf_event_pmu.c:325:18: note: call to 'realloc' here
> > 325 | new_um = realloc(perf_um, perf_um_count * 
> > sizeof(*new_um));
> > |  ^
> >   cc1: all warnings being treated as errors
> >
> > Also, pointer arithmetic on unallocated region are, perhaps, undefined
> > behavior by C standard. So even though this math looks safe on x86 this
> > should be fixed anyway to be more portable.
> >
> > Thanks,
> >
From a7b26272d8327ad1c001456a18518a0ac65dc2bb Mon Sep 17 00:00:00 2001
From: Stephane Eranian 
Date: Wed, 8 Jun 2022 06:55:36 -0700
Subject: [PATCH] avoid GCC-12 use-after-free warnings

gcc-12 seems to complain about bogus use-after-free situations in the
libpfm4 code:

p = realloc(q, ...)
if (!p)
   return NULL

s = p + (q - z)

It complains because of the use of q after realloc in this case.
Yet  q - z is just pointer artihmetic and is not dereferencing any
memory through the pointer q which may have been freed by realloc.

Fix is to pre-computer the delta before realloc to avoid using the
pointer after the call.

Reported-by: Vitaly Chikunov 
Signed-off-by: Stephane Eranian 
---
 lib/pfmlib_perf_event_pmu.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/lib/pfmlib_perf_event_pmu.c b/lib/pfmlib_perf_event_pmu.c
index c3386aaf4330..637c5b105559 100644
--- a/lib/pfmlib_perf_event_pmu.c
+++ b/lib/pfmlib_perf_event_pmu.c
@@ -268,6 +268,7 @@ perf_table_alloc_event(void)
 {
 	perf_event_t *new_pe;
 	perf_event_t *p;
+	size_t num_free;
 
 	/*
 	 * if we need to allocate an event and we have not yet
@@ -286,11 +287,20 @@ perf_table_alloc_event(void)
 
 	perf_pe_count += PERF_ALLOC_EVENT_COUNT;
 	
+	/*
+	 * compute number of free events left
+	 * before realloc() to avoid compiler warning (use-after-free)
+	 * even though we are simply doing pointer arithmetic and not
+	 * dereferencing the perf_pe after realloc when it may be stale
+	 * in case the memory was moved.
+	 */
+	num_free = perf_pe_free - perf_pe;
+
 	new_pe = realloc(perf_pe, perf_pe_count * sizeof(perf_event_t));
 	if (!new_pe) 
 		return NULL;
 	
-	perf_pe_free = new_pe + (perf_pe_free - perf_pe);
+	perf_pe_free = new_pe + num_free;
 	perf_pe_end = perf_pe_free + PERF_ALLOC_EVENT_COUNT;
 	perf_pe = new_pe;
 
@@ -315,18 +325,27 @@ static perf_umask_t *
 perf_table_alloc_umask(void)
 {
 	perf_umask_t *new_um;
+	size_t num_free;
 
 retry:
 	if (perf_um_free < perf_um_end)
 		return perf_um_free++;
 
 	perf_um_count += PERF_ALLOC_UMASK_COUNT;
-	
+
+	/*
+	 * compute number of free unmasks left
+	 * before realloc() to avoid compiler warning (use-after-free)
+	 * even though we are simply doing pointer arithmetic and not
+	 * dereferencing the perf_um after realloc when it may be stale
+	 * in case the memory was moved.
+	 */
+	num_free = perf_um_free - perf_um;
 	new_um = realloc(perf_um, perf_um_count * sizeof(*new_um));
 	if (!new_um) 
 		return NULL;
 	
-	perf_um_free = new_um + (perf_um_free - perf_um);
+	perf_um_free = new_um + num_free;
 	perf_um_end = perf_um_free + PERF_ALLOC_UMASK_COUNT;
 	perf_um = new_um;
 
-- 
2.25.1

___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] validate_power.c for power10 - was Re: Power10 support for perfmon2/libpfm

[Stephane Eranian via perfmon2-devel]

Hi Will,


Please send me the patches directly and I will review them soon.
I also want to make sure that the Power 10 PMU doc supporting the
patches is available to the public.

Thanks.

On Mon, Jul 18, 2022 at 9:00 AM William Cohen  wrote:
>
> On 5/12/22 15:40, will schmidt wrote:
> > On Wed, 2022-05-11 at 14:37 -0400, William Cohen wrote:
> >> On 5/10/22 16:52, will schmidt wrote:
> >>> On Wed, 2022-05-04 at 10:51 -0400, William Cohen wrote:
>  On 2/23/22 14:42, will schmidt wrote:
> > On Wed, 2022-02-23 at 10:33 -0500, William Cohen wrote:
> >> On 2/18/22 17:17, will schmidt wrote:
> >>> Hi,
> >>>I've created a fork of perfmon2/libpfm and pushed
> >>> the powerpc/power10 support into that fork.
> >>>
> >>>
> > 
> >> Also should there be some tests for the power10 PMU events added
> >> to
> >> tests/validate_power.c?
> >>
> >> -Will Cohen
> >>
> >
> > Hi,
> >
> > I've spun up the changes to validate_power.c for power10, tested,
> > and pushed
> > them to my fork.
> >
> > [ I'm not familiar with the incantations, but the info
> > below should be sufficient to get at the patch :-)]
> >
> > https://sourceforge.net/u/willschm/perfmon2/ci/a3fd768a5879c93d43377b89450568c9fe9cb0d6/
> >
> > git clone https://git.code.sf.net/u/willschm/perfmon2 willschm-perfmon2
> >
> > commit a3fd768a5879c93d43377b89450568c9fe9cb0d6 (HEAD -> master,
> > origin/master, origin/HEAD,
> > refs/patches/master/pushed.perfmon_libpfm_update_verification_test.
> > diff
> > )
> > Author: Will Schmidt 
> > Date:   Wed Feb 23 12:34:30 2022 -0600
> >
> > Add power10 to tests/validate_power.c
> >
> > Update perfmon/tests/validate_power.c to add entries
> > for power10.
> > Tested successfully in a Power10 environment.
> >
> > Thanks
> > -Will
> >
> 
>  Hi,
> 
>  What is the status of these patches for power10?  They are still not
>  in the upstream libpfm master git repository.
> >>>
> >>> Hi,
> >>>
> >>> A few minutes ago I pushed this patch to my perfmon fork.
> >>>
> >>> This particular commit is at
> >>> https://sourceforge.net/u/willschm/perfmon2/ci/60918a39237a0502fdd3de99a37d39a3d78100bb/
> >>>
> >>> with the tree itself available via
> >>> git clone https://git.code.sf.net/u/willschm/perfmon2 willschm-perfmon2
> >>>
> >>> The relevant detail within is:
> >>>
> >>> /*
> >>>  * Documentation on the PMU events for Power10 can be found
> >>>  * in Appendix E of the Power10 Users Manual.
> >>>  * The Power10 manual is at
> >>>  *https://ibm.ent.box.com/v/power10usermanual
> >>>  * This and other PowerPC related documents can be found at
> >>>  *https://www-50.ibm.com/systems/power/openpower/
> >>>  */
> >>>
> >>>
> >>> Thanks
> >>> -Will (Schmidt)
> >>>
> >>
> >> Hi Will Schmidt,
> >>
> >>
> >> Thanks for the update with the pointer to the power10 event documentation. 
> >>  I was looking though the patches and noticed that following patch has 
> >> PFM_PMU_POWER10 below the "/* MUST ADD NEW PMU MODELS HERE */" in 
> >> pfmlib.h. That comment should be adjacent to the PFM_PMU_MAX.
> >>
> >> https://sourceforge.net/u/willschm/perfmon2/ci/61697515bbc09d7568bd50665f3934bebc0c0485/
> >
> >
> > Corrected and pushed to the fork.
> >
> > https://sourceforge.net/u/willschm/perfmon2/ci/1db75b57c0ef6f8c9655059c7f033ddbd8908a4c/
> >
> >>
> >> What is the utility of the  enum power10_events? They are being used to 
> >> put the events in specific spots in the power10_pe[], but it looks like 
> >> the way things are generated
> >> that the entries would end up at those locations in the array anyway.  
> >> Eliminating those would reduce 
> >> https://sourceforge.net/u/willschm/perfmon2/ci/3d783a6db770885d5eddafb390faf146a64d0acd/
> >>  by 950+ lines.
> >
> > Done.Changes made, 950+ lines eliminated.   Verified it all still works 
> > OK.   This also touched each of the structure entries to remove the 
> > constants.
> > Changes pushed to fork.
> >
> >
> >>
> >> The POWER9 has descriptions (.pme_sort_desc and .pme_long_desc) for 
> >> virtually all the events.  For POWER10 some of the events don't have 
> >> descriptions.  The _ALTx event don't have a descriptions, but the first 
> >> event has a description.  Like:
> >>
> >
> >
> > Corrected, changes pushed to fork ( this change was included in the commit 
> > that eliminated the enum).
> > https://sourceforge.net/u/willschm/perfmon2/ci/1e61e646068c4e6678bfdbea30689831ab52bee7
> >
> >
> >
> > That should complete the correction of all of the issues that were 
> > identified so far.  Thanks for the review, etc.
> >
> >
> > https://sourceforge.net/u/willschm/perfmon2/ci/1e61e646068c4e6678bfdbea30689831ab52bee7/log/?path=
> >
> >
> >
> > Thanks
> > -Will (Schmidt)
>
> Hi Will Schmidt and Stephane,
>
> The power10 patches look reasonable with the remove of the unneeded 

Re: [perfmon2] validate_power.c for power10 - was Re: Power10 support for perfmon2/libpfm

[Stephane Eranian via perfmon2-devel]

Hi Will.

Power10 patch applied.
Thanks for your contributions.

On Mon, Jul 18, 2022 at 9:00 AM William Cohen  wrote:
>
> On 5/12/22 15:40, will schmidt wrote:
> > On Wed, 2022-05-11 at 14:37 -0400, William Cohen wrote:
> >> On 5/10/22 16:52, will schmidt wrote:
> >>> On Wed, 2022-05-04 at 10:51 -0400, William Cohen wrote:
>  On 2/23/22 14:42, will schmidt wrote:
> > On Wed, 2022-02-23 at 10:33 -0500, William Cohen wrote:
> >> On 2/18/22 17:17, will schmidt wrote:
> >>> Hi,
> >>>I've created a fork of perfmon2/libpfm and pushed
> >>> the powerpc/power10 support into that fork.
> >>>
> >>>
> > 
> >> Also should there be some tests for the power10 PMU events added
> >> to
> >> tests/validate_power.c?
> >>
> >> -Will Cohen
> >>
> >
> > Hi,
> >
> > I've spun up the changes to validate_power.c for power10, tested,
> > and pushed
> > them to my fork.
> >
> > [ I'm not familiar with the incantations, but the info
> > below should be sufficient to get at the patch :-)]
> >
> > https://sourceforge.net/u/willschm/perfmon2/ci/a3fd768a5879c93d43377b89450568c9fe9cb0d6/
> >
> > git clone https://git.code.sf.net/u/willschm/perfmon2 willschm-perfmon2
> >
> > commit a3fd768a5879c93d43377b89450568c9fe9cb0d6 (HEAD -> master,
> > origin/master, origin/HEAD,
> > refs/patches/master/pushed.perfmon_libpfm_update_verification_test.
> > diff
> > )
> > Author: Will Schmidt 
> > Date:   Wed Feb 23 12:34:30 2022 -0600
> >
> > Add power10 to tests/validate_power.c
> >
> > Update perfmon/tests/validate_power.c to add entries
> > for power10.
> > Tested successfully in a Power10 environment.
> >
> > Thanks
> > -Will
> >
> 
>  Hi,
> 
>  What is the status of these patches for power10?  They are still not
>  in the upstream libpfm master git repository.
> >>>
> >>> Hi,
> >>>
> >>> A few minutes ago I pushed this patch to my perfmon fork.
> >>>
> >>> This particular commit is at
> >>> https://sourceforge.net/u/willschm/perfmon2/ci/60918a39237a0502fdd3de99a37d39a3d78100bb/
> >>>
> >>> with the tree itself available via
> >>> git clone https://git.code.sf.net/u/willschm/perfmon2 willschm-perfmon2
> >>>
> >>> The relevant detail within is:
> >>>
> >>> /*
> >>>  * Documentation on the PMU events for Power10 can be found
> >>>  * in Appendix E of the Power10 Users Manual.
> >>>  * The Power10 manual is at
> >>>  *https://ibm.ent.box.com/v/power10usermanual
> >>>  * This and other PowerPC related documents can be found at
> >>>  *https://www-50.ibm.com/systems/power/openpower/
> >>>  */
> >>>
> >>>
> >>> Thanks
> >>> -Will (Schmidt)
> >>>
> >>
> >> Hi Will Schmidt,
> >>
> >>
> >> Thanks for the update with the pointer to the power10 event documentation. 
> >>  I was looking though the patches and noticed that following patch has 
> >> PFM_PMU_POWER10 below the "/* MUST ADD NEW PMU MODELS HERE */" in 
> >> pfmlib.h. That comment should be adjacent to the PFM_PMU_MAX.
> >>
> >> https://sourceforge.net/u/willschm/perfmon2/ci/61697515bbc09d7568bd50665f3934bebc0c0485/
> >
> >
> > Corrected and pushed to the fork.
> >
> > https://sourceforge.net/u/willschm/perfmon2/ci/1db75b57c0ef6f8c9655059c7f033ddbd8908a4c/
> >
> >>
> >> What is the utility of the  enum power10_events? They are being used to 
> >> put the events in specific spots in the power10_pe[], but it looks like 
> >> the way things are generated
> >> that the entries would end up at those locations in the array anyway.  
> >> Eliminating those would reduce 
> >> https://sourceforge.net/u/willschm/perfmon2/ci/3d783a6db770885d5eddafb390faf146a64d0acd/
> >>  by 950+ lines.
> >
> > Done.Changes made, 950+ lines eliminated.   Verified it all still works 
> > OK.   This also touched each of the structure entries to remove the 
> > constants.
> > Changes pushed to fork.
> >
> >
> >>
> >> The POWER9 has descriptions (.pme_sort_desc and .pme_long_desc) for 
> >> virtually all the events.  For POWER10 some of the events don't have 
> >> descriptions.  The _ALTx event don't have a descriptions, but the first 
> >> event has a description.  Like:
> >>
> >
> >
> > Corrected, changes pushed to fork ( this change was included in the commit 
> > that eliminated the enum).
> > https://sourceforge.net/u/willschm/perfmon2/ci/1e61e646068c4e6678bfdbea30689831ab52bee7
> >
> >
> >
> > That should complete the correction of all of the issues that were 
> > identified so far.  Thanks for the review, etc.
> >
> >
> > https://sourceforge.net/u/willschm/perfmon2/ci/1e61e646068c4e6678bfdbea30689831ab52bee7/log/?path=
> >
> >
> >
> > Thanks
> > -Will (Schmidt)
>
> Hi Will Schmidt and Stephane,
>
> The power10 patches look reasonable with the remove of the unneeded defines 
> and the inclusion of a pointer to power 10 PMU.
> Stephane, do the patches need to be combined into a single pat

Re: [perfmon2] Patch for Arm Neoverse CPUs (AWS Graviton, NVIDIA Grace)

[Stephane Eranian via perfmon2-devel]

Hi John,

Thanks a lot for submitting the patches. I will review them and send
you feedback.
At first glance,  you first use N! table to then patch it to N2. Just
submit a patch with the final version of the table.
If the V1 table is identical to N2, then they can share the table.
I don't see any V2 specific patches.
Thanks.


On Thu, Jan 19, 2023 at 12:42 PM John C. Linford
 wrote:
>
> Hi Stephane,
>
> I have patches for libpfm4 that add support for the Arm Neoverse V1 (AWS 
> Graviton3) and Arm Neoverse V2 (NVIDIA Grace).  What's the best way to 
> upstream these patches?  I've posted a merge request 
> (https://sourceforge.net/p/perfmon2/libpfm4/merge-requests/21/) or I can 
> simply provide the patch file here, if that's preferred.
>
> Similarly, I've written patches for Neoverse CPU support in PAPI: 
> https://bitbucket.org/icl/papi/pull-requests/424.  Giuseppe Congiu would like 
> to see the libpfm4 patches accepted before moving forward with the PAPI 
> patches.
>
> Please let me know how I can help.  Thanks!
>
> ~John Linford


___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] Possible uninitialized variable use in function 'gen_tracepoint_table' cause build to fail when built with -Werror

[Stephane Eranian via perfmon2-devel]

Will,

Patch applied.
Thanks.


On Fri, Apr 14, 2023 at 1:33 PM William Cohen  wrote:

> When trying to build the new libpfm-4.13.0 as an rpm for various
> architectures I found that the builds failed on some machines because the
> compiler found that p could be uninitialized in gen_tracepoint_table.
> Attached is a patch that fixes that specific issue.
>
> -Will
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] Invalid event attribute for cpu_clk_unhalted.thread

[Stephane Eranian via perfmon2-devel]

Hi,

Sorry for the late reply. I had a problem with the mailing list and did not
see your msg earlier.

How are you programming this event? Is this via perf stat or something else.
You seem to be running on Intel CascadeLakeX. It supports the event you
want.
However in libpfm4, right now, it is called
cpu_clk_thread_unhalted.thread_p.
In the Intel event tables (JSON) you have two versions of the event. One is
trying
to force the event on the fixed counter that supports it. This is
cpu_clk_unhalted.thread.
But they also have cpu_clk_unhalted.thread_p (_p means programmable
counter).
And you can access these via perf stat -e.
To access the libpfm4 events with perf you need to compile the perf
tol with libpfm4
support and then you can do:
perf stat --pfm-events .

The mapping between Intel JSON and libpfm4 is as follows
Intel: cpu_clk_unhalted.thread -> libpfm4: unhalted_core_cycles
Intel: cpu_clk_unhalted.thread_p -> libpfm4:
cpu_clk_thread_unhalted.thread_p

In the end it does not make any difference which one you chose because they
both count
the same thing. The kernel will program the event in whichever counter is
available.

Hope this helps.

 I am getting the error: invalid event attribute for cpu_clk_unhalted.thread.
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] Some printf statements in libpfm need to be tweaked

[Stephane Eranian via perfmon2-devel]

Hi Will,

Patch applied.
Thanks.

On Fri, Jun 30, 2023 at 12:18 PM William Cohen  wrote:

> Hi,
> I was looking through the static analysis results of libpfm and there were
> a number of printf statements that are not quite right.  One has too many
> arguments and others are missing arguments. Attached is a patch that
> addresses the following errors in a way that looked reasonable based on
> what what was observed in the code
>
> -Will
>
>
> For the following extra arg one e->fstr is printed on a later line, so I
> suspect that the line 87 should just be printing the "]".
>
> Error: PRINTF_ARGS (CWE-685): [#def66]
> libpfm-4.13.0/lib/pfmlib_intel_x86.c:87: extra_argument: This argument was
> not used by the format string: "e->fstr".
> #   85| __pfm_vbprintf(" any=%d", reg.sel_anythr);
> #   86|
> #   87|->   __pfm_vbprintf("]", e->fstr);
> #   88|
> #   89| for (i = 1 ; i < e->count; i++)
>
>
> Below are ones with missing arguments.
>
> Suspect for the 'DPRINT("%s: ...' ones that the "s: " should be removed
> based on other DPRINT examples in the code.
>
> Error: PRINTF_ARGS (CWE-685): [#def11]
> libpfm-4.13.0/lib/pfmlib_amd64_perf_event.c:78: missing_argument: No
> argument for format specifier "%d".
> #   76|
> #   77| if (e->count > 1) {
> #   78|->   DPRINT("%s: unsupported count=%d\n", e->count);
> #   79| return PFM_ERR_NOTSUPP;
> #   80| }
>
> Following should be printing the name of the pmu, so that should be %s and
> printing out p->name.
>
> Error: PRINTF_ARGS (CWE-685): [#def14]
> libpfm-4.13.0/lib/pfmlib_common.c:1151: missing_argument: No argument for
> format specifier "%d".
> # 1149|
> # 1150| if (pfmlib_is_blacklisted_pmu(p)) {
> # 1151|->   DPRINT("%d PMU blacklisted, skipping
> initialization\n");
> # 1152| continue;
> # 1153| }
>
> Looking through the code probably meaning to print out variable str.
>
> Error: PRINTF_ARGS (CWE-685): [#def15]
> libpfm-4.13.0/lib/pfmlib_common.c:1367: missing_argument: No argument for
> format specifier "%s".
> # 1365| ainfo->equiv= NULL;
> # 1366| if (*endptr) {
> # 1367|->   DPRINT("raw umask (%s) is not a
> number\n");
> # 1368| return PFM_ERR_ATTR;
> # 1369|
>
> Following looks like it is printing  state twice.
>
> Error: PRINTF_ARGS (CWE-685): [#def34]
> libpfm-4.13.0/lib/pfmlib_intel_skx_unc_cha.c:60: missing_argument: No
> argument for format specifier "%x".
> #   58| f.val = e->codes[1];
> #   59|
> #   60|->   __pfm_vbprintf("[UNC_CHA_FILTER0=0x%"PRIx64" thread_id=%d
> source=0x%x state=0x%x"
> #   61|" state=0x%x]\n",
> #   62| f.val,
>
> Suspect for the 'DPRINT("%s: ...' ones that the "s: " should be removed
> based on other DPRINT examples in the code.
>
> Error: PRINTF_ARGS (CWE-685): [#def83]
> libpfm-4.13.0/lib/pfmlib_intel_x86_perf_event.c:100: missing_argument: No
> argument for format specifier "%d".
> #   98|
> #   99| if (e->count > 2) {
> #  100|->   DPRINT("%s: unsupported count=%d\n", e->count);
> #  101| return PFM_ERR_NOTSUPP;
> #  102| }
>
>
> -Will___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] Remove extraneous "'" from fprintf statements

[Stephane Eranian via perfmon2-devel]

Hi Will,

If I recall, these extra ' are there to enable localization formatting of
the large numbers.
Please check that this is the proper way of doing localization in printf.


On Fri, Jun 30, 2023 at 11:17 AM William Cohen  wrote:

> Looking through some static analysis of lipbfm I found minor issues in the
> format strings of some of the perf examples.  The attached patch addresses
> those.
>
> -Will___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] l3_misses and l3_accesses perf events unable to be found by pfm_get_os_event_encoding() on AMD host

[Stephane Eranian via perfmon2-devel]

Hi,

At this point. libpfm4 does not support AMD L3 PMU events. They should
be added shortly.

On Wed, Mar 6, 2024 at 3:40 PM Yunzhao Li via perfmon2-devel
 wrote:
>
> Hello,
>
> I am encountering an issue where the pfm_get_os_event_encoding() API could 
> not find l3_misses or l3_accesses perf events by running the following simple 
> code:
> ~$ pfm_test l3_misses 0
> pfm_test: cannot get encoding: event not found
> ~$ pfm_test cache-misses 0
> cache-misses event supported by libpfm
>
> ```
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(int argc, char **argv)
> {
> pfm_pmu_encode_arg_t arg;
> int ret;
> char *event_name;
> int os_encoding;
>
> if (argc != 3) {
>  fprintf(stderr, "Usage: %s  \n", argv[0]);
>  return 1;
> }
>
> event_name =argv[1];
> os_encoding = atoi(argv[2]);
>
>  ret = pfm_initialize();
>  if (ret != PFM_SUCCESS)
>errx(1, "cannot initialize library %s", pfm_strerror(ret));
>
> memset(&arg, 0, sizeof(arg));
> char* fqstr = malloc(256);
> if (!fqstr) {
>errx(1, "Failed to allocate memory for fully qualified string");
> }
>
> arg.fstr = &fqstr;
> arg.size = sizeof(arg);
>
> ret = pfm_get_os_event_encoding(event_name, PFM_PLM0|PFM_PLM3, 
> os_encoding, &arg);
> if (ret != PFM_SUCCESS)
>errx(1, "cannot get encoding: %s", pfm_strerror(ret));
> else
>printf("%s event supported by libpfm\n", event_name);
>
>free(fqstr);
>return 0;
> }
>
>
> However, these events can be successfully monitored using the perf CLI tool:
>
> ```
>  ~$sudo perf stat -a -e l3_misses,l3_accesses -- sleep 1
>
>  Performance counter stats for 'system wide':
>
>  1,122,395,814  l3_misses
>  4,398,985,531  l3_accesses
>
>1.005054759 seconds time elapsed
> ```
> The environment is running on a kernel version 6.1 with an AMD EPYC 7642 
> 48-Core Processor.
>
> Any suggestions?
> ___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel


___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] spr::TOPDOWN:SLOTS and spr::TOPDOWN:BAD_SPEC_SLOTS events have the same codes?

[Stephane Eranian via perfmon2-devel]

Hi,

Thanks for reporting the problem. I have now fixed the issue in the git repo.

On Tue, Apr 9, 2024 at 5:26 PM laksono  wrote:
>
> Hi
>
> I found that pfm_get_os_event_encoding() returns the same code for both 
> spr::TOPDOWN:SLOTS and spr::TOPDOWN:BAD_SPEC_SLOTS counters.
>
> If I run the check_events example:
>
> $ ./check_events TOPDOWN:SLOTS
> ...
> Requested Event: TOPDOWN:SLOTS
> ActualEvent: spr::TOPDOWN:SLOTS:k=1:u=1:e=0:i=0:c=0:intx=0:intxcp=0
> PMU: Intel SapphireRapid
> IDX: 1073741888
> Codes  : 0x530400
>
> $ ./check_events TOPDOWN:BAD_SPEC_SLOTS
> Requested Event: TOPDOWN:BAD_SPEC_SLOTS
> ActualEvent: 
> spr::TOPDOWN:BAD_SPEC_SLOTS:k=1:u=1:e=0:i=0:c=0:intx=0:intxcp=0
> PMU: Intel SapphireRapid
> IDX: 1073741888
> Codes  : 0x530400
>
> Other sub-events like TOPDOWN:BACKEND_BOUND_SLOTS, 
> TOPDOWN:BR_MISPREDICT_SLOTS and TOPDOWN:MEMORY_BOUND_SLOTS have correctly 
> unique codes.
>
> Interestingly, the ./showevtinfo program shows that both TOPDOWN:SLOTS and 
> TOPDOWN:BAD_SPEC_SLOTS have the sane Umask.
>
> IDX  : 1073741888
> PMU name : spr (Intel SapphireRapid)
> Name : TOPDOWN
> Equiv: None
> Flags: [hw_smpl] [speculative]
> Desc : Topdown events.
> Code : 0x0
> Umask-00 : 0x02 : PMU : [BACKEND_BOUND_SLOTS] : [hw_smpl] [speculative] : TMA 
> slots where no uops were being issued due to lack of back-end resources.
> Umask-01 : 0x04 : PMU : [BAD_SPEC_SLOTS] : [hw_smpl] [speculative] : TMA 
> slots wasted due to incorrect speculations.
> Umask-02 : 0x08 : PMU : [BR_MISPREDICT_SLOTS] : [hw_smpl] [speculative] : TMA 
> slots wasted due to incorrect speculation by branch mispredictions
> Umask-03 : 0x10 : PMU : [MEMORY_BOUND_SLOTS] : [hw_smpl] [speculative] : TBD
> Umask-04 : 0x04 : PMU : [SLOTS] : [hw_smpl] [speculative] : TMA slots 
> available for an unhalted logical processor. Fixed counter - architectural 
> event
> Umask-05 : 0x1a4 : PMU : [SLOTS_P] : [hw_smpl] [speculative] : TMA slots 
> available for an unhalted logical processor. General counter - architectural 
> event
> Modif-00 : 0x00 : PMU : [k] : monitor at priv level 0 (boolean)
> Modif-01 : 0x01 : PMU : [u] : monitor at priv level 1, 2, 3 (boolean)
> Modif-02 : 0x02 : PMU : [e] : edge level (may require counter-mask >= 1) 
> (boolean)
> Modif-03 : 0x03 : PMU : [i] : invert (boolean)
> Modif-04 : 0x04 : PMU : [c] : counter-mask in range [0-255] (integer)
> Modif-05 : 0x07 : PMU : [intx] : monitor only inside transactional memory 
> region (boolean)
> Modif-06 : 0x08 : PMU : [intxcp] : do not count occurrences inside aborted 
> transactional memory region (boolean)
>
> This is tested with Intel Sapphire Rapid CPU on Linux 4.18 using the latest 
> libpfm4 from the git repository.
>
> Laksono Adhianto
> ___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel


___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] Possible unitialized variable in the perf_examples/task.c

[Stephane Eranian via perfmon2-devel]

Hi William,

Thanks for the bug report. I have fixed the problem upstream now.

On Mon, Apr 15, 2024 at 11:59 AM William Cohen  wrote:
>
> When attempting to compile the recent checkout out of libpfm as an rpm the 
> compiler reported the following warning:
>
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
> -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  
>  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -O2 
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Wno-complain-wrong-lang -Werror=format-security 
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -Wall -Werror -Wextra 
> -Wno-unused-parameter -I. -I/home/wcohen/rpmbuild/BUILD/libpfm-4.13.0/include 
> -DCONFIG_PFMLIB_DEBUG -DCONFIG_PFMLIB_OS_LINUX -DCONFIG_PFMLIB_NOTRACEPOINT 
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Wno-complain-wrong-lang -Werror=format-security 
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -Wall -Werror -Wextra 
> -Wno-unused-parameter -I. 
> -I/home/wcohen/rpmbuild/BUILD/libpfm-4.13.0/perf_examples/../include 
> -DCONFIG_PFMLIB_DEBUG -DCONFIG_PFMLIB_OS_LINUX -DCONFIG_PFMLIB_NOTRACEPOINT 
> -I. -D_GNU_SOURCE -pthread -c task.c
> In file included from 
> /home/wcohen/rpmbuild/BUILD/libpfm-4.13.0/include/perfmon/pfmlib_perf_event.h:26,
>  from perf_util.h:30,
>  from task.c:36:
> In function ‘perf_event_open’,
> inlined from ‘parent’ at task.c:283:15:
> /home/wcohen/rpmbuild/BUILD/libpfm-4.13.0/include/perfmon/perf_event.h:604:16:
>  error: ‘group_fd’ may be used uninitialized [-Werror=maybe-uninitialized]
>   604 | return syscall(
>   |^~~~
>   605 | __NR_perf_event_open, hw_event_uptr, pid, cpu, 
> group_fd, flags);
>   | 
> ~~~
> task.c: In function ‘parent’:
> task.c:183:47: note: ‘group_fd’ was declared here
>   183 | int status, ret, i, num_fds = 0, grp, group_fd;
>   |   ^~~~
> cc1: all warnings being treated as errors
> make[1]: *** 
> [/home/wcohen/rpmbuild/BUILD/libpfm-4.13.0/perf_examples/../rules.mk:30: 
> task.o] Error 1
> make[1]: Leaving directory 
> '/home/wcohen/rpmbuild/BUILD/libpfm-4.13.0/perf_examples'
> make[1]: *** Waiting for unfinished jobs
>
>
> This appears to to be caused by git commit 
> 9410619f922facca7dab2406c58fe41a8dd61529
>
> Author: Stephane Eranian   2024-02-21 02:22:47
> Committer: Stephane Eranian   2024-02-28 23:10:14
> Parent: 2441b263f6f28c0fe80f8cee62cd2e64d75cd433 (add INTEL_X86_CODE_DUP 
> event flag for Intel PMUs)
> Child:  e84a9563f4c93dc6e530dfa55d61b150fbf51510 (Add Intel AlderLake 
> Goldencove (P-Core) core PMU support)
> Branches: master, remotes/origin/master, remotes/upstream/master
> Follows: v4.13.0
> Precedes:
>
> update task.c example to handle hybrid
>
> Cannot group event if they do not belong to the same hardware PMU.
>
> Signed-off-by: Stephane Eranian 
>
> As a workaround I initialized group_fs = -1 on line 183 of 
> perf_examples/task.c.  Is that a sensible solution?
>
> -Will
>
>
>
> ___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel


___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel

Re: [perfmon2] libpfm4 bug: "sys/ioctl.h: No such file or directory"

[Stephane Eranian via perfmon2-devel]

On Tue, Jul 16, 2024 at 6:59 PM anlex N  wrote:

> I have built libpfm4 in the [msys2](https://msys2.org) UCRT64 environment:
>
> ```shell
> me@DOOR UCRT64 /e/workspace/git.code.sf.net/p/perfmon2/libpfm4
> $ mingw32-make TOPDIR=/e/workspace/git.code.sf.net/p/perfmon2/libpfm4
> Compiling for x86_64 target
> Compiling for WINDOWS system
> mingw32-make[1]: Entering directory 'E:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/lib'
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_common.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_amd64.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_core.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_x86.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_x86_arch.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_atom.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_nhm_unc.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_nhm.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_wsm.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_snb.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_snb_unc.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_ivb.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_ivb_unc.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_ARCH_X86 -DCONFIG_PFMLIB_ARCH_X86_64
> -I. -c pfmlib_intel_hsw.c
> cc  -g -Wall -Werror -Wextra -Wno-unused-parameter -I. -IE:/workspace/
> git.code.sf.net/p/perfmon2/libpfm4/include -DCONFIG_PFMLIB_DEBUG
> -DPFMLIB_WINDOWS -DCONFIG_PFMLIB_NOTRACEPOINT -D_REENTRANT -I.
> -fvisibility=hidden -DCONFIG_PFMLIB_

Re: [perfmon2] Are redwood cove or crestmont supported?

[Stephane Eranian via perfmon2-devel]

Hi,

RedwoodCove is the core architecture used by GraniteRapids. That is
supported by libpfm4 today.
Crestmont is the core architecture used by SierraForrest, That is not yet
supported by libpfm4 today. But it should be relatively easy to add that
for the core PMU.

Thanks.



On Mon, Sep 8, 2025 at 7:11 AM Patrick Schittekat <
patrick.schitte...@gmail.com> wrote:

> Hi,
>
> Is this CPU  supported?
>
> https://www.intel.com/content/www/us/en/products/sku/237327/intel-core-ultra-7-processor-155u-12m-cache-up-to-4-80-ghz/specifications.html
>
> I think it is a meteor lake (redwood cove or crestmont).
>
> I don't see it in the list, but wanted to double check. If not, it is
> there something I can do to have it supported?
>
> --Patrick
>
> ___
> perfmon2-devel mailing list
> perfmon2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
___
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel