[v3,0/4] add support for self monitoring

  This series adds self monitoring support i.e allows to configure and
read performance measurement unit (PMU) counters in runtime without
using perf utility. This has certain adventages when application runs on
isolated cores with nohz_full kernel parameter.

Events can be read directly using rte_pmu_read() or using dedicated
tracepoint rte_eal_trace_pmu_read(). The latter will cause events to be
stored inside CTF file.

By design, all enabled events are grouped together and the same group
is attached to lcores that use self monitoring funtionality.

Events are enabled by names, which need to be read from standard
location under sysfs i.e

/sys/bus/event_source/devices/PMU/events

where PMU is a core pmu i.e one measuring cpu events. As of today
raw events are not supported.

v3:
- fix shared build
v2:
- fix problems reported by test build infra

Tomasz Duszynski (4):
  eal: add generic support for reading PMU events
  eal/arm: support reading ARM PMU events in runtime
  eal/x86: support reading Intel PMU events in runtime
  eal: add PMU support to tracing library

 app/test/meson.build                     |   1 +
 app/test/test_pmu.c                      |  47 ++
 app/test/test_trace_perf.c               |   4 +
 doc/guides/prog_guide/profile_app.rst    |  13 +
 doc/guides/prog_guide/trace_lib.rst      |  32 ++
 lib/eal/arm/include/meson.build          |   1 +
 lib/eal/arm/include/rte_pmu_pmc.h        |  39 ++
 lib/eal/arm/meson.build                  |   4 +
 lib/eal/arm/rte_pmu.c                    | 104 +++++
 lib/eal/common/eal_common_trace_points.c |   3 +
 lib/eal/common/meson.build               |   3 +
 lib/eal/common/pmu_private.h             |  41 ++
 lib/eal/common/rte_pmu.c                 | 520 +++++++++++++++++++++++
 lib/eal/include/meson.build              |   1 +
 lib/eal/include/rte_eal_trace.h          |  11 +
 lib/eal/include/rte_pmu.h                | 207 +++++++++
 lib/eal/linux/eal.c                      |   4 +
 lib/eal/version.map                      |   7 +
 lib/eal/x86/include/meson.build          |   1 +
 lib/eal/x86/include/rte_pmu_pmc.h        |  33 ++
 20 files changed, 1076 insertions(+)
 create mode 100644 app/test/test_pmu.c
 create mode 100644 lib/eal/arm/include/rte_pmu_pmc.h
 create mode 100644 lib/eal/arm/rte_pmu.c
 create mode 100644 lib/eal/common/pmu_private.h
 create mode 100644 lib/eal/common/rte_pmu.c
 create mode 100644 lib/eal/include/rte_pmu.h
 create mode 100644 lib/eal/x86/include/rte_pmu_pmc.h

--
2.25.1
  

> From: Tomasz Duszynski [mailto:tduszynski@marvell.com]
> Sent: Tuesday, 29 November 2022 10.28
> 
> This series adds self monitoring support i.e allows to configure and
> read performance measurement unit (PMU) counters in runtime without
> using perf utility. This has certain adventages when application runs
> on
> isolated cores with nohz_full kernel parameter.
> 
> Events can be read directly using rte_pmu_read() or using dedicated
> tracepoint rte_eal_trace_pmu_read(). The latter will cause events to be
> stored inside CTF file.
> 
> By design, all enabled events are grouped together and the same group
> is attached to lcores that use self monitoring funtionality.
> 
> Events are enabled by names, which need to be read from standard
> location under sysfs i.e
> 
> /sys/bus/event_source/devices/PMU/events
> 
> where PMU is a core pmu i.e one measuring cpu events. As of today
> raw events are not supported.

Hi Thomasz,

I am very interested in this patch series for fast path profiling purposes. (Not using EAL trace, but our proprietary profiler.)

However, it seems that rte_pmu_read() is quite longwinded, compared to rte_pmu_pmc_read().

But perhaps I am just worrying too much, so I will ask: What is the performance cost of using rte_pmu_read() - compared to rte_pmu_pmc_read() - in the fast path?

If there is a non-negligible difference, could you please provide an example of how to configure PMU events and use rte_pmu_pmc_read() in an application?

I would primarily be interested in data cache misses and branch mispredictions. But feel free to make your own choices for the example.
  

Hi Morten,

> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Tuesday, November 29, 2022 11:43 AM
> To: Tomasz Duszynski <tduszynski@marvell.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: [EXT] RE: [PATCH v3 0/4] add support for self monitoring
> 
> External Email
> 
> ----------------------------------------------------------------------
> > From: Tomasz Duszynski [mailto:tduszynski@marvell.com]
> > Sent: Tuesday, 29 November 2022 10.28
> >
> > This series adds self monitoring support i.e allows to configure and
> > read performance measurement unit (PMU) counters in runtime without
> > using perf utility. This has certain adventages when application runs
> > on isolated cores with nohz_full kernel parameter.
> >
> > Events can be read directly using rte_pmu_read() or using dedicated
> > tracepoint rte_eal_trace_pmu_read(). The latter will cause events to
> > be stored inside CTF file.
> >
> > By design, all enabled events are grouped together and the same group
> > is attached to lcores that use self monitoring funtionality.
> >
> > Events are enabled by names, which need to be read from standard
> > location under sysfs i.e
> >
> > /sys/bus/event_source/devices/PMU/events
> >
> > where PMU is a core pmu i.e one measuring cpu events. As of today raw
> > events are not supported.
> 
> Hi Thomasz,
> 
> I am very interested in this patch series for fast path profiling purposes. (Not using EAL trace,
> but our proprietary profiler.)
> 
> However, it seems that rte_pmu_read() is quite longwinded, compared to rte_pmu_pmc_read().
> 

We need some bit of extra logic to set thigs up before performing reading actual counter but in reality 
cycles are mostly consumed by rte_pmu_pmc_read(). This obviously differs among platforms so if you
want precise measurements you need to get your hands dirty. 

That said, below are results coming from dpdk-test after running trace_perf_autotest - just to give you some idea. 

X86-64

RTE>>trace_perf_autotest
Timer running at 3000.00MHz
            void: cycles=17.739375 ns=5.913125
             u64: cycles=17.348296 ns=5.782765
             int: cycles=17.098724 ns=5.699575
           float: cycles=17.099946 ns=5.699982
          double: cycles=17.229702 ns=5.743234
          string: cycles=31.159907 ns=10.386636
         void_fp: cycles=0.679842 ns=0.226614
        read_pmu: cycles=49.325117 ns=16.441706

ARM64 with RTE_ARM_EAL_RDTSC_USE_PMU

RTE>>trace_perf_autotest
Timer running at 2480.00MHz
            void: cycles=9.413568 ns=3.795793
             u64: cycles=9.386003 ns=3.784678
             int: cycles=9.438701 ns=3.805928
           float: cycles=9.359377 ns=3.773942
          double: cycles=9.372279 ns=3.779145
          string: cycles=24.474899 ns=9.868911
         void_fp: cycles=0.505513 ns=0.203836
        read_pmu: cycles=17.442853 ns=7.033409

> But perhaps I am just worrying too much, so I will ask: What is the performance cost of using
> rte_pmu_read() - compared to rte_pmu_pmc_read() - in the fast path?
> 
> If there is a non-negligible difference, could you please provide an example of how to configure
> PMU events and use rte_pmu_pmc_read() in an application?
> 

Series come with some docs so you can check there how to run it. 

> I would primarily be interested in data cache misses and branch mispredictions. But feel free to
> make your own choices for the example.

Raw events are not supported right now which means you don't have fine control over all events. 
You can use only events from CPU PMU (/sys/bus/event_source/devices/<PMU>/events).