tools/perf/builtin-record.c | 22 +++++++--- tools/perf/util/evsel.c | 10 +++++ tools/perf/util/evsel.h | 1 + tools/perf/util/parse-events.c | 26 +++++++++--- tools/perf/util/parse-events.l | 76 +++++++++++++++++----------------- tools/perf/util/parse-events.y | 60 ++++++++++++++++++--------- tools/perf/util/pmus.c | 20 +++++++-- tools/perf/util/stat-shadow.c | 3 +- 8 files changed, 145 insertions(+), 73 deletions(-)
At the RISC-V summit the topic of avoiding event data being in the
RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON
events being the priority when no PMU is provided so that legacy
events maybe supported via json. Originally Mark Rutland also
expressed at LPC 2023 that doing this would resolve bugs on ARM Apple
M? processors, but James Clark more recently tested this and believes
the driver issues there may not have existed or have been resolved. In
any case, it is inconsistent that with a PMU event names avoid legacy
encodings, but when wildcarding PMUs (ie without a PMU with the event
name) the legacy encodings have priority.
The patch doing this work was reverted in a v6.10 release candidate
as, even though the patch was posted for weeks and had been on
linux-next for weeks without issue, Linus was in the habit of using
explicit legacy events with unsupported precision options on his
Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles
where ARM decided to call the events bus_cycles and cycles, the latter
being also a legacy event name. ARM haven't renamed the cycles event
to a more consistent cpu_cycles and avoided the problem. With these
changes the problematic event will now be skipped, a large warning
produced, and perf record will continue for the other PMU events. This
solution was proposed by Arnaldo.
Two minor changes have been added to help with the error message and
to work around issues occurring with "perf stat metrics (shadow stat)
test".
The patches have only been tested on my x86 non-hybrid laptop.
Ian Rogers (4):
perf evsel: Add pmu_name helper
perf stat: Fix find_stat for mixed legacy/non-legacy events
perf record: Skip don't fail for events that don't open
perf parse-events: Reapply "Prefer sysfs/JSON hardware events over
legacy"
tools/perf/builtin-record.c | 22 +++++++---
tools/perf/util/evsel.c | 10 +++++
tools/perf/util/evsel.h | 1 +
tools/perf/util/parse-events.c | 26 +++++++++---
tools/perf/util/parse-events.l | 76 +++++++++++++++++-----------------
tools/perf/util/parse-events.y | 60 ++++++++++++++++++---------
tools/perf/util/pmus.c | 20 +++++++--
tools/perf/util/stat-shadow.c | 3 +-
8 files changed, 145 insertions(+), 73 deletions(-)
--
2.47.0.163.g1226f6d8fa-goog
On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote:
>
> At the RISC-V summit the topic of avoiding event data being in the
> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON
> events being the priority when no PMU is provided so that legacy
> events maybe supported via json. Originally Mark Rutland also
> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple
> M? processors, but James Clark more recently tested this and believes
> the driver issues there may not have existed or have been resolved. In
> any case, it is inconsistent that with a PMU event names avoid legacy
> encodings, but when wildcarding PMUs (ie without a PMU with the event
> name) the legacy encodings have priority.
>
> The patch doing this work was reverted in a v6.10 release candidate
> as, even though the patch was posted for weeks and had been on
> linux-next for weeks without issue, Linus was in the habit of using
> explicit legacy events with unsupported precision options on his
> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles
> where ARM decided to call the events bus_cycles and cycles, the latter
> being also a legacy event name. ARM haven't renamed the cycles event
> to a more consistent cpu_cycles and avoided the problem. With these
> changes the problematic event will now be skipped, a large warning
> produced, and perf record will continue for the other PMU events. This
> solution was proposed by Arnaldo.
>
> Two minor changes have been added to help with the error message and
> to work around issues occurring with "perf stat metrics (shadow stat)
> test".
>
> The patches have only been tested on my x86 non-hybrid laptop.
>
> Ian Rogers (4):
> perf evsel: Add pmu_name helper
> perf stat: Fix find_stat for mixed legacy/non-legacy events
> perf record: Skip don't fail for events that don't open
> perf parse-events: Reapply "Prefer sysfs/JSON hardware events over
> legacy"
>
> tools/perf/builtin-record.c | 22 +++++++---
> tools/perf/util/evsel.c | 10 +++++
> tools/perf/util/evsel.h | 1 +
> tools/perf/util/parse-events.c | 26 +++++++++---
> tools/perf/util/parse-events.l | 76 +++++++++++++++++-----------------
> tools/perf/util/parse-events.y | 60 ++++++++++++++++++---------
> tools/perf/util/pmus.c | 20 +++++++--
> tools/perf/util/stat-shadow.c | 3 +-
> 8 files changed, 145 insertions(+), 73 deletions(-)
>
Thanks for the series. Tested on RISC-V qemu with counter delegation enabled.
I am able to get the event encodings specified in the json file
instead of legacy event encodings.
--------------------------------
root@debian:~/host# ./perf stat -e cycles -e instructions -vvv ls
Control descriptor is not initialized
Opening: cycles
------------------------------------------------------------
perf_event_attr:
type 4 (cpu)
size 136
config 0x1 (cycles)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
{ bp_len, config2 } 0x7f9
------------------------------------------------------------
sys_perf_event_open: pid 424 cpu -1 group_fd -1 flags 0x8 = 3
Opening: instructions
------------------------------------------------------------
perf_event_attr:
type 4 (cpu)
size 136
config 0x2 (instructions)
sample_type IDENTIFIER
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
{ bp_len, config2 } 0x7fc
------------------------------------------------------------
sys_perf_event_open: pid 424 cpu -1 group_fd -1 flags 0x8 = 4
-----------------------------------------------------------------------------------
However, we may still have to provide the encodings in the driver for
vendors due to the reasons described in the
thread. Hopefully, we can get rid of legacy PMU events one day which
will allow us to remove those driver bindings in the future.
Tested-by: Atish Patra <atishp@rivosinc.com>
> --
> 2.47.0.163.g1226f6d8fa-goog
>
On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > > At the RISC-V summit the topic of avoiding event data being in the > RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > events being the priority when no PMU is provided so that legacy > events maybe supported via json. Originally Mark Rutland also > expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > M? processors, but James Clark more recently tested this and believes > the driver issues there may not have existed or have been resolved. In > any case, it is inconsistent that with a PMU event names avoid legacy > encodings, but when wildcarding PMUs (ie without a PMU with the event > name) the legacy encodings have priority. > > The patch doing this work was reverted in a v6.10 release candidate > as, even though the patch was posted for weeks and had been on > linux-next for weeks without issue, Linus was in the habit of using > explicit legacy events with unsupported precision options on his > Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > where ARM decided to call the events bus_cycles and cycles, the latter > being also a legacy event name. ARM haven't renamed the cycles event > to a more consistent cpu_cycles and avoided the problem. With these > changes the problematic event will now be skipped, a large warning > produced, and perf record will continue for the other PMU events. This > solution was proposed by Arnaldo. > > Two minor changes have been added to help with the error message and > to work around issues occurring with "perf stat metrics (shadow stat) > test". > > The patches have only been tested on my x86 non-hybrid laptop. Hi Atish and James, Could I get your tags for this series? The patches were originally motivated by wanting to make the behavior of events parsed like "cycles" match that of "cpu/cycles/", the PMU is wildcarded to "cpu" in the first case. This was divergent because of ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's type>, config=<encoding from event>) when a PMU name was given. This aligns with RISC-V wanting to use json encodings to avoid complexity in the PMU driver. James, could you show the neoverse with the cmn PMU behavior for perf record of "cycles:pp" due to sensitivities there. Thanks, Ian > Ian Rogers (4): > perf evsel: Add pmu_name helper > perf stat: Fix find_stat for mixed legacy/non-legacy events > perf record: Skip don't fail for events that don't open > perf parse-events: Reapply "Prefer sysfs/JSON hardware events over > legacy" > > tools/perf/builtin-record.c | 22 +++++++--- > tools/perf/util/evsel.c | 10 +++++ > tools/perf/util/evsel.h | 1 + > tools/perf/util/parse-events.c | 26 +++++++++--- > tools/perf/util/parse-events.l | 76 +++++++++++++++++----------------- > tools/perf/util/parse-events.y | 60 ++++++++++++++++++--------- > tools/perf/util/pmus.c | 20 +++++++-- > tools/perf/util/stat-shadow.c | 3 +- > 8 files changed, 145 insertions(+), 73 deletions(-) > > -- > 2.47.0.163.g1226f6d8fa-goog >
On 07/11/2024 18:51, Ian Rogers wrote: > On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: >> >> At the RISC-V summit the topic of avoiding event data being in the >> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON >> events being the priority when no PMU is provided so that legacy >> events maybe supported via json. Originally Mark Rutland also >> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple >> M? processors, but James Clark more recently tested this and believes >> the driver issues there may not have existed or have been resolved. In >> any case, it is inconsistent that with a PMU event names avoid legacy >> encodings, but when wildcarding PMUs (ie without a PMU with the event >> name) the legacy encodings have priority. >> >> The patch doing this work was reverted in a v6.10 release candidate >> as, even though the patch was posted for weeks and had been on >> linux-next for weeks without issue, Linus was in the habit of using >> explicit legacy events with unsupported precision options on his >> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles >> where ARM decided to call the events bus_cycles and cycles, the latter >> being also a legacy event name. ARM haven't renamed the cycles event >> to a more consistent cpu_cycles and avoided the problem. With these >> changes the problematic event will now be skipped, a large warning >> produced, and perf record will continue for the other PMU events. This >> solution was proposed by Arnaldo. >> >> Two minor changes have been added to help with the error message and >> to work around issues occurring with "perf stat metrics (shadow stat) >> test". >> >> The patches have only been tested on my x86 non-hybrid laptop. > > Hi Atish and James, > > Could I get your tags for this series? > > The patches were originally motivated by wanting to make the behavior > of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > wildcarded to "cpu" in the first case. This was divergent because of > ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > type>, config=<encoding from event>) when a PMU name was given. This > aligns with RISC-V wanting to use json encodings to avoid complexity > in the PMU driver. > I couldn't find the thread, but I remember fairly recently it was mentioned that RISC-V would be supporting the legacy events after all, maybe it was a comment from Atish? I'm not sure if that changes the requirements for this or not? I still can't really imagine how tooling would work if every tool has to maintain the mappings of basic events like instructions and branches. For example all the perf_event_open tests in ltp use the legacy events. And wouldn't porting existing software to RISC-V would be an issue if it doesn't behave in a similar way to what's there already? > James, could you show the neoverse with the cmn PMU behavior for perf > record of "cycles:pp" due to sensitivities there. > Yep I can check this on Monday. > Thanks, > Ian > > > > >> Ian Rogers (4): >> perf evsel: Add pmu_name helper >> perf stat: Fix find_stat for mixed legacy/non-legacy events >> perf record: Skip don't fail for events that don't open >> perf parse-events: Reapply "Prefer sysfs/JSON hardware events over >> legacy" >> >> tools/perf/builtin-record.c | 22 +++++++--- >> tools/perf/util/evsel.c | 10 +++++ >> tools/perf/util/evsel.h | 1 + >> tools/perf/util/parse-events.c | 26 +++++++++--- >> tools/perf/util/parse-events.l | 76 +++++++++++++++++----------------- >> tools/perf/util/parse-events.y | 60 ++++++++++++++++++--------- >> tools/perf/util/pmus.c | 20 +++++++-- >> tools/perf/util/stat-shadow.c | 3 +- >> 8 files changed, 145 insertions(+), 73 deletions(-) >> >> -- >> 2.47.0.163.g1226f6d8fa-goog >>
On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > > > > On 07/11/2024 18:51, Ian Rogers wrote: > > On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > >> > >> At the RISC-V summit the topic of avoiding event data being in the > >> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > >> events being the priority when no PMU is provided so that legacy > >> events maybe supported via json. Originally Mark Rutland also > >> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > >> M? processors, but James Clark more recently tested this and believes > >> the driver issues there may not have existed or have been resolved. In > >> any case, it is inconsistent that with a PMU event names avoid legacy > >> encodings, but when wildcarding PMUs (ie without a PMU with the event > >> name) the legacy encodings have priority. > >> > >> The patch doing this work was reverted in a v6.10 release candidate > >> as, even though the patch was posted for weeks and had been on > >> linux-next for weeks without issue, Linus was in the habit of using > >> explicit legacy events with unsupported precision options on his > >> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > >> where ARM decided to call the events bus_cycles and cycles, the latter > >> being also a legacy event name. ARM haven't renamed the cycles event > >> to a more consistent cpu_cycles and avoided the problem. With these > >> changes the problematic event will now be skipped, a large warning > >> produced, and perf record will continue for the other PMU events. This > >> solution was proposed by Arnaldo. > >> > >> Two minor changes have been added to help with the error message and > >> to work around issues occurring with "perf stat metrics (shadow stat) > >> test". > >> > >> The patches have only been tested on my x86 non-hybrid laptop. > > > > Hi Atish and James, > > > > Could I get your tags for this series? > > Hi Ian, Thanks for your patches. It definitely helps to have a clean slate implementation for the perf tool. However, I have some open questions about other use cases that we discussed during the RVI Summit. > > The patches were originally motivated by wanting to make the behavior > > of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > > wildcarded to "cpu" in the first case. This was divergent because of > > ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > > config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > > type>, config=<encoding from event>) when a PMU name was given. This > > aligns with RISC-V wanting to use json encodings to avoid complexity > > in the PMU driver. > > > > I couldn't find the thread, but I remember fairly recently it was > mentioned that RISC-V would be supporting the legacy events after all, > maybe it was a comment from Atish? I'm not sure if that changes the > requirements for this or not? > > I still can't really imagine how tooling would work if every tool has to > maintain the mappings of basic events like instructions and branches. > For example all the perf_event_open tests in ltp use the legacy events. > No it has not changed. While this series helps to avoid clunky vendor specific encodings in the driver for perf tool, I am still unsure how we will manage other applications (directly passing legacy events through perf_event_open or perf_evlist__open) will work. I have only anecdotal data about folks relying perf legacy events directly to profile their application. All of them use mostly cycle/instruction events though. Are there any users who use other legacy events directly without perf tool ? If not, we may have only cycle/instruction mapping in the driver and rely on json for everything else. The other use case is virtualization. I have been playing with these patches to find a clean solution to enable all the use cases. If you have any other ideas, please let me know. > And wouldn't porting existing software to RISC-V would be an issue if it > doesn't behave in a similar way to what's there already? > > > James, could you show the neoverse with the cmn PMU behavior for perf > > record of "cycles:pp" due to sensitivities there. > > > > Yep I can check this on Monday. > > > Thanks, > > Ian > > > > > > > > > > > >> Ian Rogers (4): > >> perf evsel: Add pmu_name helper > >> perf stat: Fix find_stat for mixed legacy/non-legacy events > >> perf record: Skip don't fail for events that don't open > >> perf parse-events: Reapply "Prefer sysfs/JSON hardware events over > >> legacy" > >> > >> tools/perf/builtin-record.c | 22 +++++++--- > >> tools/perf/util/evsel.c | 10 +++++ > >> tools/perf/util/evsel.h | 1 + > >> tools/perf/util/parse-events.c | 26 +++++++++--- > >> tools/perf/util/parse-events.l | 76 +++++++++++++++++----------------- > >> tools/perf/util/parse-events.y | 60 ++++++++++++++++++--------- > >> tools/perf/util/pmus.c | 20 +++++++-- > >> tools/perf/util/stat-shadow.c | 3 +- > >> 8 files changed, 145 insertions(+), 73 deletions(-) > >> > >> -- > >> 2.47.0.163.g1226f6d8fa-goog > >>
On 08/11/2024 6:37 pm, Atish Kumar Patra wrote: > On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: >> >> >> >> On 07/11/2024 18:51, Ian Rogers wrote: >>> On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: >>>> >>>> At the RISC-V summit the topic of avoiding event data being in the >>>> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON >>>> events being the priority when no PMU is provided so that legacy >>>> events maybe supported via json. Originally Mark Rutland also >>>> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple >>>> M? processors, but James Clark more recently tested this and believes >>>> the driver issues there may not have existed or have been resolved. In >>>> any case, it is inconsistent that with a PMU event names avoid legacy >>>> encodings, but when wildcarding PMUs (ie without a PMU with the event >>>> name) the legacy encodings have priority. >>>> >>>> The patch doing this work was reverted in a v6.10 release candidate >>>> as, even though the patch was posted for weeks and had been on >>>> linux-next for weeks without issue, Linus was in the habit of using >>>> explicit legacy events with unsupported precision options on his >>>> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles >>>> where ARM decided to call the events bus_cycles and cycles, the latter >>>> being also a legacy event name. ARM haven't renamed the cycles event >>>> to a more consistent cpu_cycles and avoided the problem. With these >>>> changes the problematic event will now be skipped, a large warning >>>> produced, and perf record will continue for the other PMU events. This >>>> solution was proposed by Arnaldo. >>>> >>>> Two minor changes have been added to help with the error message and >>>> to work around issues occurring with "perf stat metrics (shadow stat) >>>> test". >>>> >>>> The patches have only been tested on my x86 non-hybrid laptop. >>> >>> Hi Atish and James, >>> >>> Could I get your tags for this series? >>> > > Hi Ian, > Thanks for your patches. It definitely helps to have a clean slate > implementation > for the perf tool. However, I have some open questions about other use cases > that we discussed during the RVI Summit. > >>> The patches were originally motivated by wanting to make the behavior >>> of events parsed like "cycles" match that of "cpu/cycles/", the PMU is >>> wildcarded to "cpu" in the first case. This was divergent because of >>> ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, >>> config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's >>> type>, config=<encoding from event>) when a PMU name was given. This >>> aligns with RISC-V wanting to use json encodings to avoid complexity >>> in the PMU driver. >>> >> >> I couldn't find the thread, but I remember fairly recently it was >> mentioned that RISC-V would be supporting the legacy events after all, >> maybe it was a comment from Atish? I'm not sure if that changes the >> requirements for this or not? >> >> I still can't really imagine how tooling would work if every tool has to >> maintain the mappings of basic events like instructions and branches. >> For example all the perf_event_open tests in ltp use the legacy events. >> > > No it has not changed. While this series helps to avoid clunky vendor > specific encodings > in the driver for perf tool, I am still unsure how we will manage > other applications > (directly passing legacy events through perf_event_open or > perf_evlist__open) will work. > > I have only anecdotal data about folks relying perf legacy events > directly to profile > their application. All of them use mostly cycle/instruction events though. > Are there any users who use other legacy events directly without perf tool ? > > If not, we may have only cycle/instruction mapping in the driver and > rely on json for everything else. > The other use case is virtualization. I have been playing with these > patches to find a clean solution to > enable all the use cases. If you have any other ideas, please let me know. > Yeah I would expect it's mostly cycles and instructions. I searched a bit for PERF_COUNT_HW_BRANCH_MISSES and only found tool/developer type usages, which I suppose we could expect to have to handle the mappings like perf. Although it's not the easiest thing to search for and obviously that only includes open source. Usages do exist though, there are people posting on stack overflow using it, and other various bug tracker listings. So you would expect those same users to have to use raw event codes and some switch statement to pick the right one for their hardware, or use Perf.
On Mon, Nov 11, 2024 at 2:45 AM James Clark <james.clark@linaro.org> wrote: > > > > On 08/11/2024 6:37 pm, Atish Kumar Patra wrote: > > On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > >> > >> > >> > >> On 07/11/2024 18:51, Ian Rogers wrote: > >>> On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > >>>> > >>>> At the RISC-V summit the topic of avoiding event data being in the > >>>> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > >>>> events being the priority when no PMU is provided so that legacy > >>>> events maybe supported via json. Originally Mark Rutland also > >>>> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > >>>> M? processors, but James Clark more recently tested this and believes > >>>> the driver issues there may not have existed or have been resolved. In > >>>> any case, it is inconsistent that with a PMU event names avoid legacy > >>>> encodings, but when wildcarding PMUs (ie without a PMU with the event > >>>> name) the legacy encodings have priority. > >>>> > >>>> The patch doing this work was reverted in a v6.10 release candidate > >>>> as, even though the patch was posted for weeks and had been on > >>>> linux-next for weeks without issue, Linus was in the habit of using > >>>> explicit legacy events with unsupported precision options on his > >>>> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > >>>> where ARM decided to call the events bus_cycles and cycles, the latter > >>>> being also a legacy event name. ARM haven't renamed the cycles event > >>>> to a more consistent cpu_cycles and avoided the problem. With these > >>>> changes the problematic event will now be skipped, a large warning > >>>> produced, and perf record will continue for the other PMU events. This > >>>> solution was proposed by Arnaldo. > >>>> > >>>> Two minor changes have been added to help with the error message and > >>>> to work around issues occurring with "perf stat metrics (shadow stat) > >>>> test". > >>>> > >>>> The patches have only been tested on my x86 non-hybrid laptop. > >>> > >>> Hi Atish and James, > >>> > >>> Could I get your tags for this series? > >>> > > > > Hi Ian, > > Thanks for your patches. It definitely helps to have a clean slate > > implementation > > for the perf tool. However, I have some open questions about other use cases > > that we discussed during the RVI Summit. > > > >>> The patches were originally motivated by wanting to make the behavior > >>> of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > >>> wildcarded to "cpu" in the first case. This was divergent because of > >>> ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > >>> config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > >>> type>, config=<encoding from event>) when a PMU name was given. This > >>> aligns with RISC-V wanting to use json encodings to avoid complexity > >>> in the PMU driver. > >>> > >> > >> I couldn't find the thread, but I remember fairly recently it was > >> mentioned that RISC-V would be supporting the legacy events after all, > >> maybe it was a comment from Atish? I'm not sure if that changes the > >> requirements for this or not? > >> > >> I still can't really imagine how tooling would work if every tool has to > >> maintain the mappings of basic events like instructions and branches. > >> For example all the perf_event_open tests in ltp use the legacy events. > >> > > > > No it has not changed. While this series helps to avoid clunky vendor > > specific encodings > > in the driver for perf tool, I am still unsure how we will manage > > other applications > > (directly passing legacy events through perf_event_open or > > perf_evlist__open) will work. > > > > I have only anecdotal data about folks relying perf legacy events > > directly to profile > > their application. All of them use mostly cycle/instruction events though. > > Are there any users who use other legacy events directly without perf tool ? > > > > If not, we may have only cycle/instruction mapping in the driver and > > rely on json for everything else. > > The other use case is virtualization. I have been playing with these > > patches to find a clean solution to > > enable all the use cases. If you have any other ideas, please let me know. > > > > Yeah I would expect it's mostly cycles and instructions. I searched a > bit for PERF_COUNT_HW_BRANCH_MISSES and only found tool/developer type > usages, which I suppose we could expect to have to handle the mappings > like perf. Although it's not the easiest thing to search for and > obviously that only includes open source. > > Usages do exist though, there are people posting on stack overflow using > it, and other various bug tracker listings. So you would expect those > same users to have to use raw event codes and some switch statement to > pick the right one for their hardware, or use Perf. I don't have any magic to solve this. My thoughts: 1) I thought legacy events were just going to hang around forever, although the name hinting they'd kind of been deprecated. At LPC '23 Atish and Mark Rutland originally asked for the sysfs/json to be the preference. I thought Kan was going to push back given the upheaval, especially updating every test expectation. It went through but we're in this weird state where wildcard events are encoded using legacy and PMU specifying events aren't. What this series hopes to solve. 2) I think it is important that perf tool be a reference implementation where others can look (strace, etc.) to base their implementation. Moving perf to sysfs/json is 1 step closer to legacy event deprecation. Please yell if deprecation isn't what is wanted as personally other than cleanliness I don't mind. If we do decide not to have sysfs/json be the priority then I think it sensible to revert the changes making it the priority for events that specify a PMU. I'd like some level of consistency. 3) I'd like event parsing to be a library that is as easy to link against as libbpf (i.e. not a viral license). Event parsing is really just mapping an event name to 1 or more perf_event_attr. The PMU abstraction is tied into the event parsing, but this has only been more true recently. The evsel/evlist is tied into event parsing but that feels separable. As most json isn't distributed under a viral license this feels achievable, then I suspect most tools can use this library rather than have to reinvent a wheel. Still looking for tags :-) Thanks, Ian
On 11/11/2024 5:19 pm, Ian Rogers wrote: > On Mon, Nov 11, 2024 at 2:45 AM James Clark <james.clark@linaro.org> wrote: >> >> >> >> On 08/11/2024 6:37 pm, Atish Kumar Patra wrote: >>> On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: >>>> >>>> >>>> >>>> On 07/11/2024 18:51, Ian Rogers wrote: >>>>> On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: >>>>>> >>>>>> At the RISC-V summit the topic of avoiding event data being in the >>>>>> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON >>>>>> events being the priority when no PMU is provided so that legacy >>>>>> events maybe supported via json. Originally Mark Rutland also >>>>>> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple >>>>>> M? processors, but James Clark more recently tested this and believes >>>>>> the driver issues there may not have existed or have been resolved. In >>>>>> any case, it is inconsistent that with a PMU event names avoid legacy >>>>>> encodings, but when wildcarding PMUs (ie without a PMU with the event >>>>>> name) the legacy encodings have priority. >>>>>> >>>>>> The patch doing this work was reverted in a v6.10 release candidate >>>>>> as, even though the patch was posted for weeks and had been on >>>>>> linux-next for weeks without issue, Linus was in the habit of using >>>>>> explicit legacy events with unsupported precision options on his >>>>>> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles >>>>>> where ARM decided to call the events bus_cycles and cycles, the latter >>>>>> being also a legacy event name. ARM haven't renamed the cycles event >>>>>> to a more consistent cpu_cycles and avoided the problem. With these >>>>>> changes the problematic event will now be skipped, a large warning >>>>>> produced, and perf record will continue for the other PMU events. This >>>>>> solution was proposed by Arnaldo. >>>>>> >>>>>> Two minor changes have been added to help with the error message and >>>>>> to work around issues occurring with "perf stat metrics (shadow stat) >>>>>> test". >>>>>> >>>>>> The patches have only been tested on my x86 non-hybrid laptop. >>>>> >>>>> Hi Atish and James, >>>>> >>>>> Could I get your tags for this series? >>>>> >>> >>> Hi Ian, >>> Thanks for your patches. It definitely helps to have a clean slate >>> implementation >>> for the perf tool. However, I have some open questions about other use cases >>> that we discussed during the RVI Summit. >>> >>>>> The patches were originally motivated by wanting to make the behavior >>>>> of events parsed like "cycles" match that of "cpu/cycles/", the PMU is >>>>> wildcarded to "cpu" in the first case. This was divergent because of >>>>> ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, >>>>> config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's >>>>> type>, config=<encoding from event>) when a PMU name was given. This >>>>> aligns with RISC-V wanting to use json encodings to avoid complexity >>>>> in the PMU driver. >>>>> >>>> >>>> I couldn't find the thread, but I remember fairly recently it was >>>> mentioned that RISC-V would be supporting the legacy events after all, >>>> maybe it was a comment from Atish? I'm not sure if that changes the >>>> requirements for this or not? >>>> >>>> I still can't really imagine how tooling would work if every tool has to >>>> maintain the mappings of basic events like instructions and branches. >>>> For example all the perf_event_open tests in ltp use the legacy events. >>>> >>> >>> No it has not changed. While this series helps to avoid clunky vendor >>> specific encodings >>> in the driver for perf tool, I am still unsure how we will manage >>> other applications >>> (directly passing legacy events through perf_event_open or >>> perf_evlist__open) will work. >>> >>> I have only anecdotal data about folks relying perf legacy events >>> directly to profile >>> their application. All of them use mostly cycle/instruction events though. >>> Are there any users who use other legacy events directly without perf tool ? >>> >>> If not, we may have only cycle/instruction mapping in the driver and >>> rely on json for everything else. >>> The other use case is virtualization. I have been playing with these >>> patches to find a clean solution to >>> enable all the use cases. If you have any other ideas, please let me know. >>> >> >> Yeah I would expect it's mostly cycles and instructions. I searched a >> bit for PERF_COUNT_HW_BRANCH_MISSES and only found tool/developer type >> usages, which I suppose we could expect to have to handle the mappings >> like perf. Although it's not the easiest thing to search for and >> obviously that only includes open source. >> >> Usages do exist though, there are people posting on stack overflow using >> it, and other various bug tracker listings. So you would expect those >> same users to have to use raw event codes and some switch statement to >> pick the right one for their hardware, or use Perf. > > I don't have any magic to solve this. My thoughts: > > 1) I thought legacy events were just going to hang around forever, > although the name hinting they'd kind of been deprecated. At LPC '23 > Atish and Mark Rutland originally asked for the sysfs/json to be the > preference. I thought Kan was going to push back given the upheaval, > especially updating every test expectation. It went through but we're > in this weird state where wildcard events are encoded using legacy and > PMU specifying events aren't. What this series hopes to solve. > > 2) I think it is important that perf tool be a reference > implementation where others can look (strace, etc.) to base their > implementation. Moving perf to sysfs/json is 1 step closer to legacy > event deprecation. Please yell if deprecation isn't what is wanted as > personally other than cleanliness I don't mind. If we do decide not to > have sysfs/json be the priority then I think it sensible to revert the > changes making it the priority for events that specify a PMU. I'd like > some level of consistency. Personally this change feels like it's encouraging fragmentation, the cleanest would be if RISC-V supports the legacy events like the other platforms. It's not a huge set of events anyway, and then existing software continues to work in addition to Perf continuing to work. If we're still thinking that RISC-V will support the legacy events anyway in the future, then it weakens the argument to change this and risk any breakages that fall out of it. I'm also not sure whether they really are legacy or just a common base set of events. Since the extended type thing was added even the legacy events support hybrid, so it's not like they expired from lack of features. Even if we claim they're legacy, is that really ever going to make them go away? Although I admit nobody has come out with a definitive use case that doesn't use either the cycles or instructions events, so maybe its all fine. > > 3) I'd like event parsing to be a library that is as easy to link > against as libbpf (i.e. not a viral license). Event parsing is really > just mapping an event name to 1 or more perf_event_attr. The PMU > abstraction is tied into the event parsing, but this has only been > more true recently. The evsel/evlist is tied into event parsing but > that feels separable. As most json isn't distributed under a viral > license this feels achievable, then I suspect most tools can use this > library rather than have to reinvent a wheel. > > Still looking for tags :-) > > Thanks, > Ian
On Tue, Nov 12, 2024 at 6:22 AM James Clark <james.clark@linaro.org> wrote: > > On 11/11/2024 5:19 pm, Ian Rogers wrote: > > On Mon, Nov 11, 2024 at 2:45 AM James Clark <james.clark@linaro.org> wrote: > >> > >> On 08/11/2024 6:37 pm, Atish Kumar Patra wrote: > >>> On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > >>>> > >>>> > >>>> > >>>> On 07/11/2024 18:51, Ian Rogers wrote: > >>>>> On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > >>>>>> > >>>>>> At the RISC-V summit the topic of avoiding event data being in the > >>>>>> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > >>>>>> events being the priority when no PMU is provided so that legacy > >>>>>> events maybe supported via json. Originally Mark Rutland also > >>>>>> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > >>>>>> M? processors, but James Clark more recently tested this and believes > >>>>>> the driver issues there may not have existed or have been resolved. In > >>>>>> any case, it is inconsistent that with a PMU event names avoid legacy > >>>>>> encodings, but when wildcarding PMUs (ie without a PMU with the event > >>>>>> name) the legacy encodings have priority. > >>>>>> > >>>>>> The patch doing this work was reverted in a v6.10 release candidate > >>>>>> as, even though the patch was posted for weeks and had been on > >>>>>> linux-next for weeks without issue, Linus was in the habit of using > >>>>>> explicit legacy events with unsupported precision options on his > >>>>>> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > >>>>>> where ARM decided to call the events bus_cycles and cycles, the latter > >>>>>> being also a legacy event name. ARM haven't renamed the cycles event > >>>>>> to a more consistent cpu_cycles and avoided the problem. With these > >>>>>> changes the problematic event will now be skipped, a large warning > >>>>>> produced, and perf record will continue for the other PMU events. This > >>>>>> solution was proposed by Arnaldo. > >>>>>> > >>>>>> Two minor changes have been added to help with the error message and > >>>>>> to work around issues occurring with "perf stat metrics (shadow stat) > >>>>>> test". > >>>>>> > >>>>>> The patches have only been tested on my x86 non-hybrid laptop. > >>>>> > >>>>> Hi Atish and James, > >>>>> > >>>>> Could I get your tags for this series? > >>>>> > >>> > >>> Hi Ian, > >>> Thanks for your patches. It definitely helps to have a clean slate > >>> implementation > >>> for the perf tool. However, I have some open questions about other use cases > >>> that we discussed during the RVI Summit. > >>> > >>>>> The patches were originally motivated by wanting to make the behavior > >>>>> of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > >>>>> wildcarded to "cpu" in the first case. This was divergent because of > >>>>> ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > >>>>> config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > >>>>> type>, config=<encoding from event>) when a PMU name was given. This > >>>>> aligns with RISC-V wanting to use json encodings to avoid complexity > >>>>> in the PMU driver. > >>>>> > >>>> > >>>> I couldn't find the thread, but I remember fairly recently it was > >>>> mentioned that RISC-V would be supporting the legacy events after all, > >>>> maybe it was a comment from Atish? I'm not sure if that changes the > >>>> requirements for this or not? > >>>> > >>>> I still can't really imagine how tooling would work if every tool has to > >>>> maintain the mappings of basic events like instructions and branches. > >>>> For example all the perf_event_open tests in ltp use the legacy events. > >>>> > >>> > >>> No it has not changed. While this series helps to avoid clunky vendor > >>> specific encodings > >>> in the driver for perf tool, I am still unsure how we will manage > >>> other applications > >>> (directly passing legacy events through perf_event_open or > >>> perf_evlist__open) will work. > >>> > >>> I have only anecdotal data about folks relying perf legacy events > >>> directly to profile > >>> their application. All of them use mostly cycle/instruction events though. > >>> Are there any users who use other legacy events directly without perf tool ? > >>> > >>> If not, we may have only cycle/instruction mapping in the driver and > >>> rely on json for everything else. > >>> The other use case is virtualization. I have been playing with these > >>> patches to find a clean solution to > >>> enable all the use cases. If you have any other ideas, please let me know. > >>> > >> > >> Yeah I would expect it's mostly cycles and instructions. I searched a > >> bit for PERF_COUNT_HW_BRANCH_MISSES and only found tool/developer type > >> usages, which I suppose we could expect to have to handle the mappings > >> like perf. Although it's not the easiest thing to search for and > >> obviously that only includes open source. > >> > >> Usages do exist though, there are people posting on stack overflow using > >> it, and other various bug tracker listings. So you would expect those > >> same users to have to use raw event codes and some switch statement to > >> pick the right one for their hardware, or use Perf. > > > > I don't have any magic to solve this. My thoughts: > > > > 1) I thought legacy events were just going to hang around forever, > > although the name hinting they'd kind of been deprecated. At LPC '23 > > Atish and Mark Rutland originally asked for the sysfs/json to be the > > preference. I thought Kan was going to push back given the upheaval, > > especially updating every test expectation. It went through but we're > > in this weird state where wildcard events are encoded using legacy and > > PMU specifying events aren't. What this series hopes to solve. > > > > 2) I think it is important that perf tool be a reference > > implementation where others can look (strace, etc.) to base their > > implementation. Moving perf to sysfs/json is 1 step closer to legacy > > event deprecation. Please yell if deprecation isn't what is wanted as > > personally other than cleanliness I don't mind. If we do decide not to > > have sysfs/json be the priority then I think it sensible to revert the > > changes making it the priority for events that specify a PMU. I'd like > > some level of consistency. > > Personally this change feels like it's encouraging fragmentation, the > cleanest would be if RISC-V supports the legacy events like the other > platforms. It's not a huge set of events anyway, and then existing > software continues to work in addition to Perf continuing to work. So I try to be agnostic on the issue but we got to this point because of events being broken on ARM Apple chips. I fixed an issue where the ARM core PMU appeared as an uncore PMU as ARM's PMU naming differs from everyone else's. That fix made it so we used legacy events for the ARM core PMU, the PMU driver didn't handle this correctly (at the time) on ARM Apple Linux breaking perf over multiple Linux releases affecting a number of users. Having a pool of standard events isn't on the face of it a crazy idea, I'll try to remember things that have come up: 1) instructions and cycles seem like fairly easy events to agree upon. However, we also have cpu-cycles that means cycles. With legacy events the hyphen is often used as a PMU separator. Now what does the cpu mean here? On ARM you also have cpu_cycles as a sysfs event, ie an underscore and not a hyphen: https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/drivers/perf/arm_pmuv3.c?h=perf-tools-next#n192 What does 'cpu' mean when ARM has no core PMU called 'cpu' and in heterogeneous systems there are multiple notions of 'cpu' for the core PMU. What's my point? Just trying to make a minimal 2 event set of common events with the way things currently parse leads to ambiguity. 2) missing/ambiguous legacy events. Beyond instructions and cycles there are cache references, cache misses, branch instructions, branch misses, bus cycles, stalled cycles frontend, stalled cycles backend and reference CPU cycles. This set of events captures an out-of-order machine with a single bus, but even then there's ambiguity over whether the events include speculatively executed instructions or not. What's my point? Using these events leads to unpredictable counts in software. With a sysfs/json event there is a description but none was ever given about what these legacy events should do, or do if you have a system with >1 bus, counts for speculatively executed instructions, isn't out-of-order, etc. 3) "legacy cache" events never really took off. The legacy cache event names encoded data around speculation and appeared less ambiguous, a good source for all the names supported by perf is here: https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/evsel.c?h=perf-tools-next#n734 but choices were made like prefetch is the same as a speculative read in the encoding. Vendors no doubt agree and disagree on this. LLC and L2 are synonyms, but today LLC generally means L3 and often an entirely separate PMU. What's my point? The code tried to do a smarter less ambiguous thing than PERF_TYPE_HARDWARE with PERF_TYPE_HW_CACHE but again it was flawed, carried too many architectural assumptions and without the drivers adopting it neither did users. 4) PMU drivers mapping issues and the aforementioned ARM Apple Linux breakage, RISC-V wanting to keep mappings out of a more simplistic driver. So I wasn't there for all of this, but I think this is what led to the legacy events effectively becoming deprecated. > If we're still thinking that RISC-V will support the legacy events > anyway in the future, then it weakens the argument to change this and > risk any breakages that fall out of it. Agreed, that's why I keep saying I'm only doing this because ARM and RISC-V want it. What I want is that for things like the encoding of "cpu-cycles" and "cpu/cpu-cycles/" when there is only 1 PMU providing such an event called "cpu" the perf_event_attr encodings should match, we don't have this today but did prior to changing the priority to fix the ARM Apple Linux issue. I think for what Atish is asking for perhaps the best route is to add vendor standard events like ARM has. Anything done in Linux won't carry over to other operating systems you can be trying to virtualize. This doesn't to me feel like a problem we should be trying to solve either in the kernel/driver or the tool, well I've not heard an idea how we can. > I'm also not sure whether they really are legacy or just a common base > set of events. Since the extended type thing was added even the legacy > events support hybrid, so it's not like they expired from lack of > features. Even if we claim they're legacy, is that really ever going to > make them go away? So for heterogeneous chips ARM first did BIG.little over ten years ago. More recently Intel did hybrid and it wasn't until Intel added hybrid support for legacy events that the idea of this worked. As you know, ARM''s support came later. Does software outside of the perf tool know to encode information in the extended type information in legacy events? I doubt it. For example, libpfm4 has only recently been adding support for heterogeneous CPUs. So yes there are legacy events and they are a common pool of events which is convenient for developers, however, this approach quickly showed shortcomings and often lacked proper vendor support. My company advocates developers against using common events, which admittedly is more work for the developer, because we've had multiple issues over the years primarily due to baked in assumptions. Thanks, Ian > Although I admit nobody has come out with a definitive use case that > doesn't use either the cycles or instructions events, so maybe its all fine. > > > > > 3) I'd like event parsing to be a library that is as easy to link > > against as libbpf (i.e. not a viral license). Event parsing is really > > just mapping an event name to 1 or more perf_event_attr. The PMU > > abstraction is tied into the event parsing, but this has only been > > more true recently. The evsel/evlist is tied into event parsing but > > that feels separable. As most json isn't distributed under a viral > > license this feels achievable, then I suspect most tools can use this > > library rather than have to reinvent a wheel. > > > > Still looking for tags :-) > > > > Thanks, > > Ian >
On Tue, Nov 12, 2024 at 9:23 AM Ian Rogers <irogers@google.com> wrote: > > On Tue, Nov 12, 2024 at 6:22 AM James Clark <james.clark@linaro.org> wrote: > > > > On 11/11/2024 5:19 pm, Ian Rogers wrote: > > > On Mon, Nov 11, 2024 at 2:45 AM James Clark <james.clark@linaro.org> wrote: > > >> > > >> On 08/11/2024 6:37 pm, Atish Kumar Patra wrote: > > >>> On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > > >>>> > > >>>> > > >>>> > > >>>> On 07/11/2024 18:51, Ian Rogers wrote: > > >>>>> On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > > >>>>>> > > >>>>>> At the RISC-V summit the topic of avoiding event data being in the > > >>>>>> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > > >>>>>> events being the priority when no PMU is provided so that legacy > > >>>>>> events maybe supported via json. Originally Mark Rutland also > > >>>>>> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > > >>>>>> M? processors, but James Clark more recently tested this and believes > > >>>>>> the driver issues there may not have existed or have been resolved. In > > >>>>>> any case, it is inconsistent that with a PMU event names avoid legacy > > >>>>>> encodings, but when wildcarding PMUs (ie without a PMU with the event > > >>>>>> name) the legacy encodings have priority. > > >>>>>> > > >>>>>> The patch doing this work was reverted in a v6.10 release candidate > > >>>>>> as, even though the patch was posted for weeks and had been on > > >>>>>> linux-next for weeks without issue, Linus was in the habit of using > > >>>>>> explicit legacy events with unsupported precision options on his > > >>>>>> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > > >>>>>> where ARM decided to call the events bus_cycles and cycles, the latter > > >>>>>> being also a legacy event name. ARM haven't renamed the cycles event > > >>>>>> to a more consistent cpu_cycles and avoided the problem. With these > > >>>>>> changes the problematic event will now be skipped, a large warning > > >>>>>> produced, and perf record will continue for the other PMU events. This > > >>>>>> solution was proposed by Arnaldo. > > >>>>>> > > >>>>>> Two minor changes have been added to help with the error message and > > >>>>>> to work around issues occurring with "perf stat metrics (shadow stat) > > >>>>>> test". > > >>>>>> > > >>>>>> The patches have only been tested on my x86 non-hybrid laptop. > > >>>>> > > >>>>> Hi Atish and James, > > >>>>> > > >>>>> Could I get your tags for this series? > > >>>>> > > >>> > > >>> Hi Ian, > > >>> Thanks for your patches. It definitely helps to have a clean slate > > >>> implementation > > >>> for the perf tool. However, I have some open questions about other use cases > > >>> that we discussed during the RVI Summit. > > >>> > > >>>>> The patches were originally motivated by wanting to make the behavior > > >>>>> of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > > >>>>> wildcarded to "cpu" in the first case. This was divergent because of > > >>>>> ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > > >>>>> config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > > >>>>> type>, config=<encoding from event>) when a PMU name was given. This > > >>>>> aligns with RISC-V wanting to use json encodings to avoid complexity > > >>>>> in the PMU driver. > > >>>>> > > >>>> > > >>>> I couldn't find the thread, but I remember fairly recently it was > > >>>> mentioned that RISC-V would be supporting the legacy events after all, > > >>>> maybe it was a comment from Atish? I'm not sure if that changes the > > >>>> requirements for this or not? > > >>>> > > >>>> I still can't really imagine how tooling would work if every tool has to > > >>>> maintain the mappings of basic events like instructions and branches. > > >>>> For example all the perf_event_open tests in ltp use the legacy events. > > >>>> > > >>> > > >>> No it has not changed. While this series helps to avoid clunky vendor > > >>> specific encodings > > >>> in the driver for perf tool, I am still unsure how we will manage > > >>> other applications > > >>> (directly passing legacy events through perf_event_open or > > >>> perf_evlist__open) will work. > > >>> > > >>> I have only anecdotal data about folks relying perf legacy events > > >>> directly to profile > > >>> their application. All of them use mostly cycle/instruction events though. > > >>> Are there any users who use other legacy events directly without perf tool ? > > >>> > > >>> If not, we may have only cycle/instruction mapping in the driver and > > >>> rely on json for everything else. > > >>> The other use case is virtualization. I have been playing with these > > >>> patches to find a clean solution to > > >>> enable all the use cases. If you have any other ideas, please let me know. > > >>> > > >> > > >> Yeah I would expect it's mostly cycles and instructions. I searched a > > >> bit for PERF_COUNT_HW_BRANCH_MISSES and only found tool/developer type > > >> usages, which I suppose we could expect to have to handle the mappings > > >> like perf. Although it's not the easiest thing to search for and > > >> obviously that only includes open source. > > >> > > >> Usages do exist though, there are people posting on stack overflow using > > >> it, and other various bug tracker listings. So you would expect those > > >> same users to have to use raw event codes and some switch statement to > > >> pick the right one for their hardware, or use Perf. > > > > > > I don't have any magic to solve this. My thoughts: > > > > > > 1) I thought legacy events were just going to hang around forever, > > > although the name hinting they'd kind of been deprecated. At LPC '23 > > > Atish and Mark Rutland originally asked for the sysfs/json to be the > > > preference. I thought Kan was going to push back given the upheaval, > > > especially updating every test expectation. It went through but we're > > > in this weird state where wildcard events are encoded using legacy and > > > PMU specifying events aren't. What this series hopes to solve. > > > > > > 2) I think it is important that perf tool be a reference > > > implementation where others can look (strace, etc.) to base their > > > implementation. Moving perf to sysfs/json is 1 step closer to legacy > > > event deprecation. Please yell if deprecation isn't what is wanted as > > > personally other than cleanliness I don't mind. If we do decide not to > > > have sysfs/json be the priority then I think it sensible to revert the > > > changes making it the priority for events that specify a PMU. I'd like > > > some level of consistency. > > > > Personally this change feels like it's encouraging fragmentation, the > > cleanest would be if RISC-V supports the legacy events like the other > > platforms. It's not a huge set of events anyway, and then existing > > software continues to work in addition to Perf continuing to work. > > So I try to be agnostic on the issue but we got to this point because > of events being broken on ARM Apple chips. I fixed an issue where the > ARM core PMU appeared as an uncore PMU as ARM's PMU naming differs > from everyone else's. That fix made it so we used legacy events for > the ARM core PMU, the PMU driver didn't handle this correctly (at the > time) on ARM Apple Linux breaking perf over multiple Linux releases > affecting a number of users. > > Having a pool of standard events isn't on the face of it a crazy idea, > I'll try to remember things that have come up: > > 1) instructions and cycles seem like fairly easy events to agree upon. > However, we also have cpu-cycles that means cycles. With legacy events > the hyphen is often used as a PMU separator. Now what does the cpu > mean here? On ARM you also have cpu_cycles as a sysfs event, ie an > underscore and not a hyphen: > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/drivers/perf/arm_pmuv3.c?h=perf-tools-next#n192 > What does 'cpu' mean when ARM has no core PMU called 'cpu' and in > heterogeneous systems there are multiple notions of 'cpu' for the core > PMU. > What's my point? Just trying to make a minimal 2 event set of common > events with the way things currently parse leads to ambiguity. > > 2) missing/ambiguous legacy events. Beyond instructions and cycles > there are cache references, cache misses, branch instructions, branch > misses, bus cycles, stalled cycles frontend, stalled cycles backend > and reference CPU cycles. This set of events captures an out-of-order > machine with a single bus, but even then there's ambiguity over > whether the events include speculatively executed instructions or not. > What's my point? Using these events leads to unpredictable counts in > software. With a sysfs/json event there is a description but none was > ever given about what these legacy events should do, or do if you have > a system with >1 bus, counts for speculatively executed instructions, > isn't out-of-order, etc. > > 3) "legacy cache" events never really took off. The legacy cache event > names encoded data around speculation and appeared less ambiguous, a > good source for all the names supported by perf is here: > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/evsel.c?h=perf-tools-next#n734 > but choices were made like prefetch is the same as a speculative read > in the encoding. Vendors no doubt agree and disagree on this. LLC and > L2 are synonyms, but today LLC generally means L3 and often an > entirely separate PMU. > What's my point? The code tried to do a smarter less ambiguous thing > than PERF_TYPE_HARDWARE with PERF_TYPE_HW_CACHE but again it was > flawed, carried too many architectural assumptions and without the > drivers adopting it neither did users. > > 4) PMU drivers mapping issues and the aforementioned ARM Apple Linux > breakage, RISC-V wanting to keep mappings out of a more simplistic > driver. > > So I wasn't there for all of this, but I think this is what led to the > legacy events effectively becoming deprecated. > > > If we're still thinking that RISC-V will support the legacy events > > anyway in the future, then it weakens the argument to change this and > > risk any breakages that fall out of it. > > Agreed, that's why I keep saying I'm only doing this because ARM and > RISC-V want it. What I want is that for things like the encoding of In the beginning, we wanted it for the RISC-V ecosystem because we had an opportunity to start from a clean slate and attempt a better implementation. However, the burden of supporting the existing existing users who try to run their preferred way of profiling applications by using legacy events (especially cycle/instructions) are forcing us to follow the convention (have the encodings specified in the driver as well. ) unfortunately. However, we can add the encodings under a Kconfig which can be disabled or removed in the future if we get to a point where there are no legacy users. > "cpu-cycles" and "cpu/cpu-cycles/" when there is only 1 PMU providing > such an event called "cpu" the perf_event_attr encodings should match, > we don't have this today but did prior to changing the priority to fix > the ARM Apple Linux issue. > > I think for what Atish is asking for perhaps the best route is to add > vendor standard events like ARM has. Anything done in Linux won't > carry over to other operating systems you can be trying to virtualize. > This doesn't to me feel like a problem we should be trying to solve > either in the kernel/driver or the tool, well I've not heard an idea > how we can. > Apart from the non-Linux guests using SBI PMU events, the host hypervisor(also running Linux) may need event mapping available in the driver for the following reasons even for guests running Linux. 1. The guest Linux is not running the updated perf tool with the correct json file 2. VMM wants to fake the unique identifiers (vendorid, archid, implid) for migration or some other reasons. Both these use cases are probably corner cases at best. That's why, I am inclined to keep the encoding in the driver to begin with with the hope we won't need to serve these use cases in the future. The driver will use the raw events coming from json as a preferred method for all the events anyways. In that case, the hypervisor doesn't have to do anything apart from filtering. In absence of it, the events are encoded as legacy (HARDWARE or HARDWARE_CACHE) and the hypervisor will try its best to map those to a platform specific encoding. > > I'm also not sure whether they really are legacy or just a common base > > set of events. Since the extended type thing was added even the legacy > > events support hybrid, so it's not like they expired from lack of > > features. Even if we claim they're legacy, is that really ever going to > > make them go away? > > So for heterogeneous chips ARM first did BIG.little over ten years > ago. More recently Intel did hybrid and it wasn't until Intel added > hybrid support for legacy events that the idea of this worked. As you > know, ARM''s support came later. Does software outside of the perf > tool know to encode information in the extended type information in > legacy events? I doubt it. For example, libpfm4 has only recently been > adding support for heterogeneous CPUs. > > So yes there are legacy events and they are a common pool of events > which is convenient for developers, however, this approach quickly > showed shortcomings and often lacked proper vendor support. My company > advocates developers against using common events, which admittedly is > more work for the developer, because we've had multiple issues over > the years primarily due to baked in assumptions. > > Thanks, > Ian > > > Although I admit nobody has come out with a definitive use case that > > doesn't use either the cycles or instructions events, so maybe its all fine. > > > > > > > > 3) I'd like event parsing to be a library that is as easy to link > > > against as libbpf (i.e. not a viral license). Event parsing is really > > > just mapping an event name to 1 or more perf_event_attr. The PMU > > > abstraction is tied into the event parsing, but this has only been > > > more true recently. The evsel/evlist is tied into event parsing but > > > that feels separable. As most json isn't distributed under a viral > > > license this feels achievable, then I suspect most tools can use this > > > library rather than have to reinvent a wheel. > > > > > > Still looking for tags :-) > > > > > > Thanks, > > > Ian > >
On Mon, Nov 11, 2024 at 9:19 AM Ian Rogers <irogers@google.com> wrote: > > On Mon, Nov 11, 2024 at 2:45 AM James Clark <james.clark@linaro.org> wrote: > > > > > > > > On 08/11/2024 6:37 pm, Atish Kumar Patra wrote: > > > On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > > >> > > >> > > >> > > >> On 07/11/2024 18:51, Ian Rogers wrote: > > >>> On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > > >>>> > > >>>> At the RISC-V summit the topic of avoiding event data being in the > > >>>> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > > >>>> events being the priority when no PMU is provided so that legacy > > >>>> events maybe supported via json. Originally Mark Rutland also > > >>>> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > > >>>> M? processors, but James Clark more recently tested this and believes > > >>>> the driver issues there may not have existed or have been resolved. In > > >>>> any case, it is inconsistent that with a PMU event names avoid legacy > > >>>> encodings, but when wildcarding PMUs (ie without a PMU with the event > > >>>> name) the legacy encodings have priority. > > >>>> > > >>>> The patch doing this work was reverted in a v6.10 release candidate > > >>>> as, even though the patch was posted for weeks and had been on > > >>>> linux-next for weeks without issue, Linus was in the habit of using > > >>>> explicit legacy events with unsupported precision options on his > > >>>> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > > >>>> where ARM decided to call the events bus_cycles and cycles, the latter > > >>>> being also a legacy event name. ARM haven't renamed the cycles event > > >>>> to a more consistent cpu_cycles and avoided the problem. With these > > >>>> changes the problematic event will now be skipped, a large warning > > >>>> produced, and perf record will continue for the other PMU events. This > > >>>> solution was proposed by Arnaldo. > > >>>> > > >>>> Two minor changes have been added to help with the error message and > > >>>> to work around issues occurring with "perf stat metrics (shadow stat) > > >>>> test". > > >>>> > > >>>> The patches have only been tested on my x86 non-hybrid laptop. > > >>> > > >>> Hi Atish and James, > > >>> > > >>> Could I get your tags for this series? > > >>> > > > > > > Hi Ian, > > > Thanks for your patches. It definitely helps to have a clean slate > > > implementation > > > for the perf tool. However, I have some open questions about other use cases > > > that we discussed during the RVI Summit. > > > > > >>> The patches were originally motivated by wanting to make the behavior > > >>> of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > > >>> wildcarded to "cpu" in the first case. This was divergent because of > > >>> ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > > >>> config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > > >>> type>, config=<encoding from event>) when a PMU name was given. This > > >>> aligns with RISC-V wanting to use json encodings to avoid complexity > > >>> in the PMU driver. > > >>> > > >> > > >> I couldn't find the thread, but I remember fairly recently it was > > >> mentioned that RISC-V would be supporting the legacy events after all, > > >> maybe it was a comment from Atish? I'm not sure if that changes the > > >> requirements for this or not? > > >> > > >> I still can't really imagine how tooling would work if every tool has to > > >> maintain the mappings of basic events like instructions and branches. > > >> For example all the perf_event_open tests in ltp use the legacy events. > > >> > > > > > > No it has not changed. While this series helps to avoid clunky vendor > > > specific encodings > > > in the driver for perf tool, I am still unsure how we will manage > > > other applications > > > (directly passing legacy events through perf_event_open or > > > perf_evlist__open) will work. > > > > > > I have only anecdotal data about folks relying perf legacy events > > > directly to profile > > > their application. All of them use mostly cycle/instruction events though. > > > Are there any users who use other legacy events directly without perf tool ? > > > > > > If not, we may have only cycle/instruction mapping in the driver and > > > rely on json for everything else. > > > The other use case is virtualization. I have been playing with these > > > patches to find a clean solution to > > > enable all the use cases. If you have any other ideas, please let me know. > > > > > > > Yeah I would expect it's mostly cycles and instructions. I searched a > > bit for PERF_COUNT_HW_BRANCH_MISSES and only found tool/developer type > > usages, which I suppose we could expect to have to handle the mappings > > like perf. Although it's not the easiest thing to search for and > > obviously that only includes open source. > > > > Usages do exist though, there are people posting on stack overflow using > > it, and other various bug tracker listings. So you would expect those > > same users to have to use raw event codes and some switch statement to > > pick the right one for their hardware, or use Perf. > > I don't have any magic to solve this. My thoughts: > > 1) I thought legacy events were just going to hang around forever, > although the name hinting they'd kind of been deprecated. At LPC '23 > Atish and Mark Rutland originally asked for the sysfs/json to be the > preference. I thought Kan was going to push back given the upheaval, > especially updating every test expectation. It went through but we're > in this weird state where wildcard events are encoded using legacy and > PMU specifying events aren't. What this series hopes to solve. > > 2) I think it is important that perf tool be a reference > implementation where others can look (strace, etc.) to base their > implementation. Moving perf to sysfs/json is 1 step closer to legacy > event deprecation. Please yell if deprecation isn't what is wanted as > personally other than cleanliness I don't mind. If we do decide not to > have sysfs/json be the priority then I think it sensible to revert the > changes making it the priority for events that specify a PMU. I'd like > some level of consistency. > > 3) I'd like event parsing to be a library that is as easy to link > against as libbpf (i.e. not a viral license). Event parsing is really > just mapping an event name to 1 or more perf_event_attr. The PMU > abstraction is tied into the event parsing, but this has only been > more true recently. The evsel/evlist is tied into event parsing but > that feels separable. As most json isn't distributed under a viral > license this feels achievable, then I suspect most tools can use this > library rather than have to reinvent a wheel. That would be the ideal solution IMHO for any other tools. For virtualization, the guest OS would pass the event attribute as RAW if the matching json file is present. The hypervisor would simply program that in mhpmevent CSR. In absence of the json file, guest OS would pass the legacy event encoding which must be mapped to a vendor specific encoding present in the driver. Hopefully, this can be removed in the future once legacy events are deprecated. Thoughts ? > > Still looking for tags :-) > Done. Sorry for the delay. Just wanted to ensure that this solutions works properly for all the above cases I mentioned. > Thanks, > Ian
On Fri, Nov 8, 2024 at 10:38 AM Atish Kumar Patra <atishp@rivosinc.com> wrote: > > On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > > > > > > > > On 07/11/2024 18:51, Ian Rogers wrote: > > > On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > > >> > > >> At the RISC-V summit the topic of avoiding event data being in the > > >> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > > >> events being the priority when no PMU is provided so that legacy > > >> events maybe supported via json. Originally Mark Rutland also > > >> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > > >> M? processors, but James Clark more recently tested this and believes > > >> the driver issues there may not have existed or have been resolved. In > > >> any case, it is inconsistent that with a PMU event names avoid legacy > > >> encodings, but when wildcarding PMUs (ie without a PMU with the event > > >> name) the legacy encodings have priority. > > >> > > >> The patch doing this work was reverted in a v6.10 release candidate > > >> as, even though the patch was posted for weeks and had been on > > >> linux-next for weeks without issue, Linus was in the habit of using > > >> explicit legacy events with unsupported precision options on his > > >> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > > >> where ARM decided to call the events bus_cycles and cycles, the latter > > >> being also a legacy event name. ARM haven't renamed the cycles event > > >> to a more consistent cpu_cycles and avoided the problem. With these > > >> changes the problematic event will now be skipped, a large warning > > >> produced, and perf record will continue for the other PMU events. This > > >> solution was proposed by Arnaldo. > > >> > > >> Two minor changes have been added to help with the error message and > > >> to work around issues occurring with "perf stat metrics (shadow stat) > > >> test". > > >> > > >> The patches have only been tested on my x86 non-hybrid laptop. > > > > > > Hi Atish and James, > > > > > > Could I get your tags for this series? > > > > > Hi Ian, > Thanks for your patches. It definitely helps to have a clean slate > implementation > for the perf tool. However, I have some open questions about other use cases > that we discussed during the RVI Summit. Thanks Atish, could I get your acked/reviewed/tested tags? Ian > > > The patches were originally motivated by wanting to make the behavior > > > of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > > > wildcarded to "cpu" in the first case. This was divergent because of > > > ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > > > config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > > > type>, config=<encoding from event>) when a PMU name was given. This > > > aligns with RISC-V wanting to use json encodings to avoid complexity > > > in the PMU driver. > > > > > > > I couldn't find the thread, but I remember fairly recently it was > > mentioned that RISC-V would be supporting the legacy events after all, > > maybe it was a comment from Atish? I'm not sure if that changes the > > requirements for this or not? > > > > I still can't really imagine how tooling would work if every tool has to > > maintain the mappings of basic events like instructions and branches. > > For example all the perf_event_open tests in ltp use the legacy events. > > > > No it has not changed. While this series helps to avoid clunky vendor > specific encodings > in the driver for perf tool, I am still unsure how we will manage > other applications > (directly passing legacy events through perf_event_open or > perf_evlist__open) will work. > > I have only anecdotal data about folks relying perf legacy events > directly to profile > their application. All of them use mostly cycle/instruction events though. > Are there any users who use other legacy events directly without perf tool ? > > If not, we may have only cycle/instruction mapping in the driver and > rely on json for everything else. > The other use case is virtualization. I have been playing with these > patches to find a clean solution to > enable all the use cases. If you have any other ideas, please let me know. > > > And wouldn't porting existing software to RISC-V would be an issue if it > > doesn't behave in a similar way to what's there already? > > > > > James, could you show the neoverse with the cmn PMU behavior for perf > > > record of "cycles:pp" due to sensitivities there. > > > > > > > Yep I can check this on Monday. > > > > > Thanks, > > > Ian > > > > > > > > > > > > > > > > > > >> Ian Rogers (4): > > >> perf evsel: Add pmu_name helper > > >> perf stat: Fix find_stat for mixed legacy/non-legacy events > > >> perf record: Skip don't fail for events that don't open > > >> perf parse-events: Reapply "Prefer sysfs/JSON hardware events over > > >> legacy" > > >> > > >> tools/perf/builtin-record.c | 22 +++++++--- > > >> tools/perf/util/evsel.c | 10 +++++ > > >> tools/perf/util/evsel.h | 1 + > > >> tools/perf/util/parse-events.c | 26 +++++++++--- > > >> tools/perf/util/parse-events.l | 76 +++++++++++++++++----------------- > > >> tools/perf/util/parse-events.y | 60 ++++++++++++++++++--------- > > >> tools/perf/util/pmus.c | 20 +++++++-- > > >> tools/perf/util/stat-shadow.c | 3 +- > > >> 8 files changed, 145 insertions(+), 73 deletions(-) > > >> > > >> -- > > >> 2.47.0.163.g1226f6d8fa-goog > > >>
On Fri, Nov 8, 2024 at 11:00 AM Ian Rogers <irogers@google.com> wrote: > > On Fri, Nov 8, 2024 at 10:38 AM Atish Kumar Patra <atishp@rivosinc.com> wrote: > > > > On Fri, Nov 8, 2024 at 4:16 AM James Clark <james.clark@linaro.org> wrote: > > > > > > > > > > > > On 07/11/2024 18:51, Ian Rogers wrote: > > > > On Sat, Oct 26, 2024 at 5:18 AM Ian Rogers <irogers@google.com> wrote: > > > >> > > > >> At the RISC-V summit the topic of avoiding event data being in the > > > >> RISC-V PMU kernel driver came up. There is a preference for sysfs/JSON > > > >> events being the priority when no PMU is provided so that legacy > > > >> events maybe supported via json. Originally Mark Rutland also > > > >> expressed at LPC 2023 that doing this would resolve bugs on ARM Apple > > > >> M? processors, but James Clark more recently tested this and believes > > > >> the driver issues there may not have existed or have been resolved. In > > > >> any case, it is inconsistent that with a PMU event names avoid legacy > > > >> encodings, but when wildcarding PMUs (ie without a PMU with the event > > > >> name) the legacy encodings have priority. > > > >> > > > >> The patch doing this work was reverted in a v6.10 release candidate > > > >> as, even though the patch was posted for weeks and had been on > > > >> linux-next for weeks without issue, Linus was in the habit of using > > > >> explicit legacy events with unsupported precision options on his > > > >> Neoverse-N1. This machine has SLC PMU events for bus and CPU cycles > > > >> where ARM decided to call the events bus_cycles and cycles, the latter > > > >> being also a legacy event name. ARM haven't renamed the cycles event > > > >> to a more consistent cpu_cycles and avoided the problem. With these > > > >> changes the problematic event will now be skipped, a large warning > > > >> produced, and perf record will continue for the other PMU events. This > > > >> solution was proposed by Arnaldo. > > > >> > > > >> Two minor changes have been added to help with the error message and > > > >> to work around issues occurring with "perf stat metrics (shadow stat) > > > >> test". > > > >> > > > >> The patches have only been tested on my x86 non-hybrid laptop. > > > > > > > > Hi Atish and James, > > > > > > > > Could I get your tags for this series? > > > > > > > > Hi Ian, > > Thanks for your patches. It definitely helps to have a clean slate > > implementation > > for the perf tool. However, I have some open questions about other use cases > > that we discussed during the RVI Summit. > > Thanks Atish, could I get your acked/reviewed/tested tags? > Sure. I will finish the testing and send those. > Ian > > > > > The patches were originally motivated by wanting to make the behavior > > > > of events parsed like "cycles" match that of "cpu/cycles/", the PMU is > > > > wildcarded to "cpu" in the first case. This was divergent because of > > > > ARM we switched from preferring legacy (type = PERF_TYPE_HARDWARE, > > > > config = PERF_COUNT_HW_CPU_CYCLES) to sysfs/json (type=<core PMU's > > > > type>, config=<encoding from event>) when a PMU name was given. This > > > > aligns with RISC-V wanting to use json encodings to avoid complexity > > > > in the PMU driver. > > > > > > > > > > I couldn't find the thread, but I remember fairly recently it was > > > mentioned that RISC-V would be supporting the legacy events after all, > > > maybe it was a comment from Atish? I'm not sure if that changes the > > > requirements for this or not? > > > > > > I still can't really imagine how tooling would work if every tool has to > > > maintain the mappings of basic events like instructions and branches. > > > For example all the perf_event_open tests in ltp use the legacy events. > > > > > > > No it has not changed. While this series helps to avoid clunky vendor > > specific encodings > > in the driver for perf tool, I am still unsure how we will manage > > other applications > > (directly passing legacy events through perf_event_open or > > perf_evlist__open) will work. > > > > I have only anecdotal data about folks relying perf legacy events > > directly to profile > > their application. All of them use mostly cycle/instruction events though. > > Are there any users who use other legacy events directly without perf tool ? > > + Michale from tensorrent who was suggesting that they use the direct perf calls in their profiling application. @Michale : Do you have more details of direct usage of perf legacy events to profile your application ? > > If not, we may have only cycle/instruction mapping in the driver and > > rely on json for everything else. > > The other use case is virtualization. I have been playing with these > > patches to find a clean solution to > > enable all the use cases. If you have any other ideas, please let me know. > > @Ian Any thoughts on this ? Let me explain the hypervisor use case a little bit more. RISC-V KVM relies on SBI PMU[1] (equivalent to hypercall in x86 or HVC in ARM). As the RISC-V ISA doesn't have any event encodings, the SBI PMU defines a standard set corresponding to each perf legacy event. When a guest tries to allocate a counter for an event, it makes an SBI call (CFG_MATCH) with SBI event encodings (matching perf legacy) or a raw event encoding. The host kernel allocates a virtual counter and programs the corresponding event CSRs and enables the counter. There are two possible approaches to support it. 1. The guest OS has the correct version of the perf tool with the json file that provides the encoding of the events supported by the running host. The guest OS passes the exact encoding of the event during the CFG_MATCH SBI call as a raw event and the host programs the event CSR. It is a much simpler scheme and less management on the host side. But the perf tool on guests has to pass any perf legacy events as raw events to the driver instead of PERF_HARDWARE/CACHE or indicate event encoding is coming from json in some other way. The other issue is that VMM can not modify the vendorid,implid,archid shown to the guest (the default is the same as the host). Migration across CPU generation or vendors won't be possible if perf in use. This may not be an issue as VM migration across CPU Generations are not a common thing. 2. The guest OS driver always relies on the SBI PMU event encoding (i.e perf legacy event) which the host can translate to the event encoding the hardware supports if it is baked into the driver. The obvious downside is the vendor specific encodings in the driver which we are trying to avoid. [1] https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/src/ext-pmu.adoc > > > And wouldn't porting existing software to RISC-V would be an issue if it > > > doesn't behave in a similar way to what's there already? > > > > > > > James, could you show the neoverse with the cmn PMU behavior for perf > > > > record of "cycles:pp" due to sensitivities there. > > > > > > > > > > Yep I can check this on Monday. > > > > > > > Thanks, > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > >> Ian Rogers (4): > > > >> perf evsel: Add pmu_name helper > > > >> perf stat: Fix find_stat for mixed legacy/non-legacy events > > > >> perf record: Skip don't fail for events that don't open > > > >> perf parse-events: Reapply "Prefer sysfs/JSON hardware events over > > > >> legacy" > > > >> > > > >> tools/perf/builtin-record.c | 22 +++++++--- > > > >> tools/perf/util/evsel.c | 10 +++++ > > > >> tools/perf/util/evsel.h | 1 + > > > >> tools/perf/util/parse-events.c | 26 +++++++++--- > > > >> tools/perf/util/parse-events.l | 76 +++++++++++++++++----------------- > > > >> tools/perf/util/parse-events.y | 60 ++++++++++++++++++--------- > > > >> tools/perf/util/pmus.c | 20 +++++++-- > > > >> tools/perf/util/stat-shadow.c | 3 +- > > > >> 8 files changed, 145 insertions(+), 73 deletions(-) > > > >> > > > >> -- > > > >> 2.47.0.163.g1226f6d8fa-goog > > > >>
© 2016 - 2026 Red Hat, Inc.