linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>
Cc: kernel@collabora.com, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	James Clark <james.clark@linaro.org>
Subject: Re: [PATCH RESEND v2] perf/headers: Document PERF_PMU_CAP capability flags
Date: Sat, 11 Oct 2025 11:11:19 +0800	[thread overview]
Message-ID: <d01d3f15-c144-4e2a-9aee-6308a897f3f2@linux.intel.com> (raw)
In-Reply-To: <20250909-perf-pmu-cap-docs-v2-1-3c451f7b0b2e@collabora.com>


On 9/9/2025 7:39 PM, Nicolas Frattaroli wrote:
> Over the years, capability flags for perf PMUs were introduced in a
>
> piecemeal fashion whenever a new driver needed to signal to the perf
>
> core some limitation or special feature.
>
>
>
> Since one more undocumented flag that can have its meaning inferred from
>
> the commit message and implementation never seems that bad, it's
>
> understandable that this resulted in a total of 11 undocumented
>
> capability flags, which authors of new perf PMU drivers are expected to
>
> set correctly for their particular device.
>
>
>
> Since I am in the process of becoming such an author of a new perf
>
> driver, it feels proper to pay it forward by documenting all
>
> PERF_PMU_CAP_ constants, so that no future person has to go through an
>
> hour or two of git blame + reading perf core code to figure out which
>
> capability flags are right for them.
>
>
>
> Add comments in kernel-doc format that describes each flag. This follows
>
> the somewhat verbose "Object-like macro documentation" format, and can
>
> be verified with
>
>
>
> 	./scripts/kernel-doc -v -none include/linux/perf_event.h
>
>
>
> The current in-tree kernel documentation does not include a page on the
>
> perf subsystem, but once it does, these comments should render as proper
>
> documentation annotation. Until then, they'll also be quite useful for
>
> anyone looking at the header file.
>
>
>
> Reviewed-by: James Clark <james.clark@linaro.org>
>
> Reviewed-by: Ian Rogers <irogers@google.com>
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
> ---
>
> Changes in v2:
>
> - Fixed the description of PERF_PMU_CAP_NO_INTERRUPT and expanded it to
>
>   make it clearer for driver authors whether this flag is right for them
>
> - Made PERF_PMU_CAP_NO_EXCLUDE docs mention the precise attributes the
>
>   flag concerns itself with, as suggested by Peter Zijlstra
>
> - Link to v1: https://lore.kernel.org/r/20250618-perf-pmu-cap-docs-v1-1-0d34387d6e47@collabora.com
>
> ---
>
>  include/linux/perf_event.h | 85 ++++++++++++++++++++++++++++++++++++++++++++++
>
>  1 file changed, 85 insertions(+)
>
>
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>
> index ec9d96025683958e909bb2463439dc69634f4ceb..d0e6b66cfd268bdad742b707633792f26352a428 100644
>
> --- a/include/linux/perf_event.h
>
> +++ b/include/linux/perf_event.h
>
> @@ -294,16 +294,101 @@ struct perf_event_pmu_context;
>
>  /**
>
>   * pmu::capabilities flags
>
>   */
>
> +
>
> +/**
>
> + * define PERF_PMU_CAP_NO_INTERRUPT - \
>
> + *    PMU is incapable of generating samples
>
> + *
>
> + * On CPU PMU hardware, a PMU driver is only capable of generating sample data
>
> + * in the form of &struct perf_sample_data if the hardware is capable of
>
> + * generating hardware interrupts. If such interrupt capability is missing,
>
> + * this flag should be set.
>
> + *
>
> + * Uncore drivers, i.e. drivers for hardware performance counters that are not
>
> + * closely entwined with CPUs and their model of execution, should also set
>
> + * this flag, as they are not able to generate meaningful sample data, even if
>
> + * they do use an interrupt for some purpose.
>
> + */
>
>  #define PERF_PMU_CAP_NO_INTERRUPT	0x0001
>
> +/**
>
> + * define PERF_PMU_CAP_NO_NMI - \
>
> + *    PMU is guaranteed to not generate non-maskable interrupts
>
> + */
>
>  #define PERF_PMU_CAP_NO_NMI		0x0002
>
> +/**
>
> + * define PERF_PMU_CAP_AUX_NO_SG - \
>
> + *    PMU does not support using scatter-gather as the output
>
> + *
>
> + * The PERF_PMU_CAP_AUX_NO_SG flag indicates that the PMU does not support
>
> + * scatter-gather for its output buffer, and needs a larger contiguous buffer
>
> + * to output to.
>
> + */
>
>  #define PERF_PMU_CAP_AUX_NO_SG		0x0004
>
> +/**
>
> + * define PERF_PMU_CAP_EXTENDED_REGS - \
>
> + *    PMU is capable of sampling extended registers
>
> + *
>
> + * Some architectures have a concept of extended registers, e.g. XMM0 on x86
>
> + * or VG on arm64. If the PMU is capable of sampling these registers, then the
>
> + * flag PERF_PMU_CAP_EXTENDED_REGS should be set.
>
> + */
>
>  #define PERF_PMU_CAP_EXTENDED_REGS	0x0008
>
> +/**
>
> + * define PERF_PMU_CAP_EXCLUSIVE - \
>
> + *    PMU can only have one scheduled event at a time
>
> + *
>
> + * Certain PMU hardware cannot track several events at the same time. Such
>
> + * hardware must set PERF_PMU_CAP_EXCLUSIVE in order to avoid conflicts.
>
> + */
>
>  #define PERF_PMU_CAP_EXCLUSIVE		0x0010
>
> +/**
>
> + * define PERF_PMU_CAP_ITRACE - PMU traces instructions
>
> + *
>
> + * Some PMU hardware does instruction tracing, in that it traces execution of
>
> + * each instruction. Setting this capability flag makes the perf core generate
>
> + * a %PERF_RECORD_ITRACE_START event, recording the profiled task's PID and TID,
>
> + * to allow tools to properly decode such traces.
>
> + */
>
>  #define PERF_PMU_CAP_ITRACE		0x0020
>
> +/**
>
> + * define PERF_PMU_CAP_NO_EXCLUDE - \
>
> + *    PMU is incapable of excluding events based on context
>
> + *
>
> + * The PERF_PMU_CAP_NO_EXCLUDE flag, when set, makes the perf core reject any
>
> + * request for an event that has one of the attributes
>
> + * perf_event_attr::exclude_{user,kernel,hv,idle,host,guest} set.
>
> + *
>
> + * Drivers for PMU hardware that cannot distinguish between these different
>
> + * execution contexts should set this flag.
>
> + */
>
>  #define PERF_PMU_CAP_NO_EXCLUDE		0x0040
>
> +/**
>
> + * define PERF_PMU_CAP_AUX_OUTPUT - PMU non-AUX events generate AUX data
>
> + *
>
> + * Drivers for PMU hardware that supports non-AUX events which generate data for
>
> + * AUX events should set PERF_PMU_CAP_AUX_OUTPUT. This flag tells the perf core
>
> + * to schedule non-AUX events together with AUX events, so that this data isn't
>
> + * lost.
>
> + */
>
>  #define PERF_PMU_CAP_AUX_OUTPUT		0x0080
>
> +/**
>
> + * define PERF_PMU_CAP_EXTENDED_HW_TYPE - \
>
> + *    PMU supports PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE
>
> + */
>
>  #define PERF_PMU_CAP_EXTENDED_HW_TYPE	0x0100
>
> +/**
>
> + * define PERF_PMU_CAP_AUX_PAUSE - \
>
> + *    PMU can pause and resume AUX area traces based on events
>
> + */
>
>  #define PERF_PMU_CAP_AUX_PAUSE		0x0200
>
> +/**
>
> + * define PERF_PMU_CAP_AUX_PREFER_LARGE - PMU prefers contiguous output buffers
>
> + *
>
> + * The PERF_PMU_CAP_AUX_PREFER_LARGE capability flag is a less strict variant of
>
> + * %PERF_PMU_CAP_AUX_NO_SG. PMU drivers for hardware that doesn't strictly
>
> + * require contiguous output buffers, but find the benefits outweigh the
>
> + * downside of increased memory fragmentation, may set this capability flag.
>
> + */
>
>  #define PERF_PMU_CAP_AUX_PREFER_LARGE	0x0400

Good to see we have comments/Doc to describe this flags. It's really
helpful for the newcomers into the Perf. Thanks.

LGTM. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>


>
>  
>
>  /**
>
>
>
> ---
>
> base-commit: 1d07605c859ee3f483f07acd461452d9e505c58c
>
> change-id: 20250618-perf-pmu-cap-docs-a13e4ae939ac
>
>
>
> Best regards,
>

      reply	other threads:[~2025-10-11  3:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-09 11:39 [PATCH RESEND v2] perf/headers: Document PERF_PMU_CAP capability flags Nicolas Frattaroli
2025-10-11  3:11 ` Mi, Dapeng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d01d3f15-c144-4e2a-9aee-6308a897f3f2@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).