About

Goal: Split current monolithic wperf-driver (Kernel driver) into small, independent drivers with well defined Kernel ↔︎ User space protocol.

Relates to WPERF-709 - Getting issue details... STATUS .

Introduction

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.

Design And Architecture

This chapter contains design and architectural decisions we agree to implement with DT feature.

All below architectural changes are a roadmap (no order in which they should be added).

Kernel - user-space Interface

Interface between user-space (wperf application and Kernel driver aka wperf-driver (and other wperf-driver-* drivers divided into logical sections and is defined by IOCTLs as follows:

Counting Interface

This supports generic Arm PMU hardware.

Counting model, for obtaining aggregate counts of occurrences of special events.

Sampling Interface

This supports generic Arm PMU hardware and other devices (such as SPE?) which can perform sampling and deliver the same typo of information to user space: PC values with hit counts.

Sampling model, for determining the frequencies of event occurrences produced by program locations at the function, basic block, and/or instruction levels.

Interoperability Interface

This interface is common amongst all drivers. It is user to query, detect, fetch hardware information from each driver.

Note: ALL DRIVERS MUST CORRECTLY AND IN THE SAME WAY (ABI) IMPLEMENT THIS INTERFACE.

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.