...

Note: Please note that this is draft, we may want to split drivers in a different way e.g. core PMU and uncore PMU as two separate drivers (not three like its stated below). See below draft of ideas and possible solutions to DT architecture. Further chapters should describe architecture we want o actually implement.

• [ON HOLD] Split current wperf-driver into three separate independent drivers (core, DSU and DMC driver).

• Introduce “driver type” for WindowsPerf drivers in DT.

  • “core PMU” driver type to support vanilla Arm PMUs.

  • “uncore PMU” driver(s):

    • Introduce “DSU” driver type to support uncore PMU counting.

    • Introduce “DMC” driver type to support Dynamic Memory Controllers.

• [ON HOLD] Introduce driver “template” for each type.

  • Note: We may want to have one template for “PMU like devices”

• [ON HOLD] Move current wperf-driver core PMU and uncore PMU implementations under new driver types.

• Add DT driver enumeration to user space.

  • Adapt wperf and drivers to communicate with N drivers installed.

  • Adapt wperf-devgen to support new driver types enumeration and installation / removal.

...

Device_ID string pattern

See:

• Implementation details:

  • https://gitlab.com/Linaro/WindowsPerf/windowsperf/-/merge_requests/548 and

  • Jira Legacy
    server System JIRA serverId 59107c6f-1e52-32bc-b58f-400d54bba998 key WPERF-728

Introduction

<dev_type>.<dev_func>=<event_prefix_list> - separated with semicolon ; for each supported "capabilities".

Where:

• <dev_type> - E.g. supported type such as:

  • core (Arm PMU),

  • dsu

  • dmc (Arm DDR controller), and

  • spe (Arm Statistical Profiling Extension).

• <dev_func>

  • stat for counting with wperf stat (also timelines)

  • sample or record for sampling with wperf sample / wperf record.

• <event_prefix_list> - list of event prefixes supported (with wperf ... -e <events>) that will indicate which device to select for the events.

Examples

Example Device_ID string for pristine wperf-driver:

core.stat=core;core.sample=core;dsu.stat=dsu;dmc.stat=dmc_clk,dmc_clkdiv2

...

Example Device_ID for each device

• core.stat=core - events starting with /core/ (or no prefix!) selected with:

  • wperf stat -e <event>

  • wperf stat -e /core/<event> or

  • will be used to count events over time.

• core.sample=core - events starting with /core/ (or no prefix!) selected with

  • wperf sample -e <event>

  • wperf sample -e /core/<event> or

  • will be used to sample events over time.

• dmc.stat=dmc_clk,dmc_clkdiv2 - events starting with /dmc_clk/or/dmc_clkdiv2/ ` selected with:

  • wperf stat -e /dmc_clk/<event> or

  • wperf stat -e /dmc_clkdiv2/<events will be used to count events over time.

Assumptions:

1. One driver can have many capabilities in their Device_ID string.

2. Driver yields data for each capability information in Device_ID string.

...

Notes

• Przemyslaw Wirkus: Changes that we may have to implement:

  • New IOCTL with WindowsPerf like detection infmroation, with payload like:

    • Capability string (ASCIIZ) e.g. "spe", "core;dsu;dmc" where "core" or "spe" are defined by us devices which can e.g. count and sample. Can be semicolon ; separated.

      • Note: "core;spe" - we would allow one driver to have more than one capability aka.

    • Functionality string (ASCIIZ) e.g. "counting" or "sampling" where we e.g that "pmu" capability comes with counting and sampling (like wperf-driver does). Can be semicolon ; separated for each capability. Example: for capability string `"core;dsu;dmc" (which would be wperf-driver capability string) we can generate below functionality string:

      • "counting,sampling;counting;counting" and it maps like this:

        • core → counting,sampling - wperf’s stat and sample / record work with events specified with -e and /core/<event> (or -e <event>).

          • Note /core/ will be also default (as it is) for events without name.

        • dsu → counting - wperf’s stat work with events specified with -e and /dsu/<events>.

        • dmc → counting - wperf’s stat work with events specified with -e and /dmc/<events>.

  • IOCTL_PMU_CTL_QUERY_HW_CFG - we may have to split this IOCTL to at least two parts, one would provide hardware information (like register values) as it’s doing now, second part would be maybe interface specific.