2024-02-08 13:19:28

by Ben Gainey

[permalink] [raw]
Subject: [PATCH v2 0/4] perf: Support PERF_SAMPLE_READ with inherit_stat

This change allows events to use PERF_SAMPLE READ with inherit so long
as both inherit_stat and PERF_SAMPLE_TID are set.

Currently it is not possible to use PERF_SAMPLE_READ with inherit. This
restriction assumes the user is interested in collecting aggregate
statistics as per `perf stat`. It prevents a user from collecting
per-thread samples using counter groups from a multi-threaded or
multi-process application, as with `perf record -e '{....}:S'`. Instead
users must use system-wide mode, or forgo the ability to sample counter
groups. System-wide mode is often problematic as it requires specific
permissions (no CAP_PERFMON / root access), or may lead to capture of
significant amounts of extra data from other processes running on the
system.

Perf already supports the ability to collect per-thread counts with
`inherit` via the `inherit_stat` flag. This patch changes
`perf_event_alloc` relaxing the restriction to combine `inherit` with
`PERF_SAMPLE_READ` so that the combination will be allowed so long as
`inherit_stat` and `PERF_SAMPLE_TID` are enabled.

In this configuration stream ids (such as may appear in the read_format
field of a PERF_RECORD_SAMPLE) are no longer globally unique, rather
the pair of (stream id, tid) uniquely identify each event. Tools that
rely on this, for example to calculate a delta between samples, would
need updating to take this into account. Previously valid event
configurations (system-wide, no-inherit and so on) where each stream id
is the identifier are unaffected.


Changes since v1:
- Rebase on v6.8-rc1
- Fixed value written into sample after child exists.
- Modified handling of switch-out so that context with these events take the
slow path, so that the per-event/per-thread PMU state is correctly switched.
- Modified perf tools to support this mode of operation.


Ben Gainey (4):
perf: Support PERF_SAMPLE_READ with inherit_stat
tools/perf: Track where perf_sample_ids need per-thread periods
tools/perf: Correctly calculate sample period for inherited
SAMPLE_READ values
tools/perf: Allow inherit + inherit_stat + PERF_SAMPLE_READ when
opening events

include/linux/perf_event.h | 1 +
kernel/events/core.c | 53 +++++++++++++++++--------
tools/lib/perf/evlist.c | 1 +
tools/lib/perf/evsel.c | 48 ++++++++++++++++++++++
tools/lib/perf/include/internal/evsel.h | 48 +++++++++++++++++++++-
tools/perf/util/evsel.c | 15 ++++++-
tools/perf/util/evsel.h | 1 +
tools/perf/util/session.c | 11 +++--
8 files changed, 154 insertions(+), 24 deletions(-)

--
2.43.0



2024-02-08 13:48:22

by Ben Gainey

[permalink] [raw]
Subject: [PATCH v2 1/4] perf: Support PERF_SAMPLE_READ with inherit_stat

This change allows events to use PERF_SAMPLE READ with inherit
so long as both inherit_stat and PERF_SAMPLE_TID are set.

In this configuration, and event will be inherited into any
child processes / threads, allowing convenient profiling of a
multiprocess or multithreaded application, whilst allowing
profiling tools to collect per-thread samples, in particular
of groups of counters.

Signed-off-by: Ben Gainey <[email protected]>
---
include/linux/perf_event.h | 1 +
kernel/events/core.c | 53 ++++++++++++++++++++++++++------------
2 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index d2a15c0c6f8a..7d405dff6694 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -932,6 +932,7 @@ struct perf_event_context {

int nr_task_data;
int nr_stat;
+ int nr_stat_read;
int nr_freq;
int rotate_disable;

diff --git a/kernel/events/core.c b/kernel/events/core.c
index f0f0f71213a1..dac7093b3608 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1795,8 +1795,11 @@ list_add_event(struct perf_event *event, struct perf_event_context *ctx)
ctx->nr_events++;
if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
ctx->nr_user++;
- if (event->attr.inherit_stat)
+ if (event->attr.inherit_stat) {
ctx->nr_stat++;
+ if (event->attr.inherit && (event->attr.sample_type & PERF_SAMPLE_READ))
+ ctx->nr_stat_read++;
+ }

if (event->state > PERF_EVENT_STATE_OFF)
perf_cgroup_event_enable(event, ctx);
@@ -2019,8 +2022,11 @@ list_del_event(struct perf_event *event, struct perf_event_context *ctx)
ctx->nr_events--;
if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
ctx->nr_user--;
- if (event->attr.inherit_stat)
+ if (event->attr.inherit_stat) {
ctx->nr_stat--;
+ if (event->attr.inherit && (event->attr.sample_type & PERF_SAMPLE_READ))
+ ctx->nr_stat_read--;
+ }

list_del_rcu(&event->event_entry);

@@ -3529,11 +3535,17 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
perf_ctx_disable(ctx, false);

/* PMIs are disabled; ctx->nr_pending is stable. */
- if (local_read(&ctx->nr_pending) ||
+ if (ctx->nr_stat_read ||
+ next_ctx->nr_stat_read ||
+ local_read(&ctx->nr_pending) ||
local_read(&next_ctx->nr_pending)) {
/*
* Must not swap out ctx when there's pending
* events that rely on the ctx->task relation.
+ *
+ * Likewise, when a context contains inherit+inherit_stat+SAMPLE_READ
+ * events they should be switched out using the slow path
+ * so that they are treated as if they were distinct contexts.
*/
raw_spin_unlock(&next_ctx->lock);
rcu_read_unlock();
@@ -3545,6 +3557,7 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)

perf_ctx_sched_task_cb(ctx, false);
perf_event_swap_task_ctx_data(ctx, next_ctx);
+ perf_event_sync_stat(ctx, next_ctx);

perf_ctx_enable(ctx, false);

@@ -3559,8 +3572,6 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
RCU_INIT_POINTER(next->perf_event_ctxp, ctx);

do_switch = 0;
-
- perf_event_sync_stat(ctx, next_ctx);
}
raw_spin_unlock(&next_ctx->lock);
raw_spin_unlock(&ctx->lock);
@@ -4533,8 +4544,13 @@ static void __perf_event_read(void *info)
raw_spin_unlock(&ctx->lock);
}

-static inline u64 perf_event_count(struct perf_event *event)
+static inline u64 perf_event_count(struct perf_event *event, bool from_sample)
{
+ if (from_sample && event->attr.inherit &&
+ event->attr.inherit &&
+ (event->attr.sample_type & PERF_SAMPLE_TID)) {
+ return local64_read(&event->count);
+ }
return local64_read(&event->count) + atomic64_read(&event->child_count);
}

@@ -5454,7 +5470,7 @@ static u64 __perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *
mutex_lock(&event->child_mutex);

(void)perf_event_read(event, false);
- total += perf_event_count(event);
+ total += perf_event_count(event, false);

*enabled += event->total_time_enabled +
atomic64_read(&event->child_total_time_enabled);
@@ -5463,7 +5479,7 @@ static u64 __perf_event_read_value(struct perf_event *event, u64 *enabled, u64 *

list_for_each_entry(child, &event->child_list, child_list) {
(void)perf_event_read(child, false);
- total += perf_event_count(child);
+ total += perf_event_count(child, false);
*enabled += child->total_time_enabled;
*running += child->total_time_running;
}
@@ -5545,14 +5561,14 @@ static int __perf_read_group_add(struct perf_event *leader,
/*
* Write {count,id} tuples for every sibling.
*/
- values[n++] += perf_event_count(leader);
+ values[n++] += perf_event_count(leader, false);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
if (read_format & PERF_FORMAT_LOST)
values[n++] = atomic64_read(&leader->lost_samples);

for_each_sibling_event(sub, leader) {
- values[n++] += perf_event_count(sub);
+ values[n++] += perf_event_count(sub, false);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
if (read_format & PERF_FORMAT_LOST)
@@ -6132,7 +6148,7 @@ void perf_event_update_userpage(struct perf_event *event)
++userpg->lock;
barrier();
userpg->index = perf_event_index(event);
- userpg->offset = perf_event_count(event);
+ userpg->offset = perf_event_count(event, false);
if (userpg->index)
userpg->offset -= local64_read(&event->hw.prev_count);

@@ -7200,7 +7216,7 @@ static void perf_output_read_one(struct perf_output_handle *handle,
u64 values[5];
int n = 0;

- values[n++] = perf_event_count(event);
+ values[n++] = perf_event_count(event, true);
if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED) {
values[n++] = enabled +
atomic64_read(&event->child_total_time_enabled);
@@ -7245,7 +7261,7 @@ static void perf_output_read_group(struct perf_output_handle *handle,
(leader->state == PERF_EVENT_STATE_ACTIVE))
leader->pmu->read(leader);

- values[n++] = perf_event_count(leader);
+ values[n++] = perf_event_count(leader, true);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(leader);
if (read_format & PERF_FORMAT_LOST)
@@ -7260,7 +7276,7 @@ static void perf_output_read_group(struct perf_output_handle *handle,
(sub->state == PERF_EVENT_STATE_ACTIVE))
sub->pmu->read(sub);

- values[n++] = perf_event_count(sub);
+ values[n++] = perf_event_count(sub, false);
if (read_format & PERF_FORMAT_ID)
values[n++] = primary_event_id(sub);
if (read_format & PERF_FORMAT_LOST)
@@ -12010,10 +12026,13 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
local64_set(&hwc->period_left, hwc->sample_period);

/*
- * We currently do not support PERF_SAMPLE_READ on inherited events.
+ * We do not support PERF_SAMPLE_READ on inherited events unless
+ * inherit_stat and PERF_SAMPLE_TID are also selected, which allows
+ * inherited events to collect per-thread samples.
* See perf_output_read().
*/
- if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ))
+ if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ)
+ && !(attr->inherit_stat && (attr->sample_type & PERF_SAMPLE_TID)))
goto err_ns;

if (!has_branch_stack(event))
@@ -13037,7 +13056,7 @@ static void sync_child_event(struct perf_event *child_event)
perf_event_read_event(child_event, task);
}

- child_val = perf_event_count(child_event);
+ child_val = perf_event_count(child_event, false);

/*
* Add back the child's count to the parent's count:
--
2.43.0


2024-03-10 13:06:58

by Ben Gainey

[permalink] [raw]
Subject: Re: [PATCH v2 0/4] perf: Support PERF_SAMPLE_READ with inherit_stat

On Thu, 2024-02-08 at 13:10 +0000, Ben Gainey wrote:
> This change allows events to use PERF_SAMPLE READ with inherit so
> long
> as both inherit_stat and PERF_SAMPLE_TID are set.
>
> Currently it is not possible to use PERF_SAMPLE_READ with inherit.
> This
> restriction assumes the user is interested in collecting aggregate
> statistics as per `perf stat`. It prevents a user from collecting
> per-thread samples using counter groups from a multi-threaded or
> multi-process application, as with `perf record -e '{....}:S'`.
> Instead
> users must use system-wide mode, or forgo the ability to sample
> counter
> groups. System-wide mode is often problematic as it requires specific
> permissions (no CAP_PERFMON / root access), or may lead to capture of
> significant amounts of extra data from other processes running on the
> system.
>
> Perf already supports the ability to collect per-thread counts with
> `inherit` via the `inherit_stat` flag. This patch changes
> `perf_event_alloc` relaxing the restriction to combine `inherit` with
> `PERF_SAMPLE_READ` so that the combination will be allowed so long as
> `inherit_stat` and `PERF_SAMPLE_TID` are enabled.
>
> In this configuration stream ids (such as may appear in the
> read_format
> field of a PERF_RECORD_SAMPLE) are no longer globally unique, rather
> the pair of (stream id, tid) uniquely identify each event. Tools that
> rely on this, for example to calculate a delta between samples, would
> need updating to take this into account. Previously valid event
> configurations (system-wide, no-inherit and so on) where each stream
> id
> is the identifier are unaffected.
>
>
> Changes since v1:
> - Rebase on v6.8-rc1
> - Fixed value written into sample after child exists.
> - Modified handling of switch-out so that context with these events
> take the
> slow path, so that the per-event/per-thread PMU state is correctly
> switched.
> - Modified perf tools to support this mode of operation.
>
>
> Ben Gainey (4):
> perf: Support PERF_SAMPLE_READ with inherit_stat
> tools/perf: Track where perf_sample_ids need per-thread periods
> tools/perf: Correctly calculate sample period for inherited
> SAMPLE_READ values
> tools/perf: Allow inherit + inherit_stat + PERF_SAMPLE_READ when
> opening events
>
> include/linux/perf_event.h | 1 +
> kernel/events/core.c | 53 +++++++++++++++++------
> --
> tools/lib/perf/evlist.c | 1 +
> tools/lib/perf/evsel.c | 48 ++++++++++++++++++++++
> tools/lib/perf/include/internal/evsel.h | 48 +++++++++++++++++++++-
> tools/perf/util/evsel.c | 15 ++++++-
> tools/perf/util/evsel.h | 1 +
> tools/perf/util/session.c | 11 +++--
> 8 files changed, 154 insertions(+), 24 deletions(-)
>



Hello all, appreciate everyone is busy. Is there any feedback on these?
I expect they will need rebasing, but before I do that, are you happy
with the approach?

Cheers
Ben
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2024-03-11 15:58:44

by James Clark

[permalink] [raw]
Subject: Re: [PATCH v2 1/4] perf: Support PERF_SAMPLE_READ with inherit_stat



On 08/02/2024 13:10, Ben Gainey wrote:
> This change allows events to use PERF_SAMPLE READ with inherit
> so long as both inherit_stat and PERF_SAMPLE_TID are set.

I saw there was a discussion on V1 about adding a new flag because this
is an ABI break. Personally I'm not sure if it is required given that it
wasn't allowed before, so there wouldn't be any users to experience it.
I suppose there _could_ be a new user if they stumbled across this now,
but it's not like they would see that as a regression because it wasn't
allowed before anyway. Maybe it's cleaner to just use the existing flags
rather than adding a new one.

Perf even guarded the condition in userspace as far as I can see, so
nobody using Perf would hit this either.

>
> In this configuration, and event will be inherited into any

and -> any/an?

> child processes / threads, allowing convenient profiling of a
> multiprocess or multithreaded application, whilst allowing
> profiling tools to collect per-thread samples, in particular
> of groups of counters.
>
> Signed-off-by: Ben Gainey <[email protected]>
> ---
> include/linux/perf_event.h | 1 +
> kernel/events/core.c | 53 ++++++++++++++++++++++++++------------
> 2 files changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index d2a15c0c6f8a..7d405dff6694 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -932,6 +932,7 @@ struct perf_event_context {
>
> int nr_task_data;
> int nr_stat;
> + int nr_stat_read;
> int nr_freq;
> int rotate_disable;
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index f0f0f71213a1..dac7093b3608 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1795,8 +1795,11 @@ list_add_event(struct perf_event *event, struct perf_event_context *ctx)
> ctx->nr_events++;
> if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
> ctx->nr_user++;
> - if (event->attr.inherit_stat)
> + if (event->attr.inherit_stat) {
> ctx->nr_stat++;
> + if (event->attr.inherit && (event->attr.sample_type & PERF_SAMPLE_READ))
> + ctx->nr_stat_read++;
> + }
>
> if (event->state > PERF_EVENT_STATE_OFF)
> perf_cgroup_event_enable(event, ctx);
> @@ -2019,8 +2022,11 @@ list_del_event(struct perf_event *event, struct perf_event_context *ctx)
> ctx->nr_events--;
> if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
> ctx->nr_user--;
> - if (event->attr.inherit_stat)
> + if (event->attr.inherit_stat) {
> ctx->nr_stat--;
> + if (event->attr.inherit && (event->attr.sample_type & PERF_SAMPLE_READ))

This condition is repeated a few times, maybe we could add a macro like
"has_sample_read_thread()" or something or whatever we're calling it
exactly.

It might have prevented the mistake in copying the condition below in
perf_event_count()...

> + ctx->nr_stat_read--;
> + }
>
> list_del_rcu(&event->event_entry);
>
> @@ -3529,11 +3535,17 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
> perf_ctx_disable(ctx, false);
>
> /* PMIs are disabled; ctx->nr_pending is stable. */
> - if (local_read(&ctx->nr_pending) ||
> + if (ctx->nr_stat_read ||
> + next_ctx->nr_stat_read ||
> + local_read(&ctx->nr_pending) ||
> local_read(&next_ctx->nr_pending)) {
> /*
> * Must not swap out ctx when there's pending
> * events that rely on the ctx->task relation.
> + *
> + * Likewise, when a context contains inherit+inherit_stat+SAMPLE_READ
> + * events they should be switched out using the slow path
> + * so that they are treated as if they were distinct contexts.
> */
> raw_spin_unlock(&next_ctx->lock);
> rcu_read_unlock();
> @@ -3545,6 +3557,7 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
>
> perf_ctx_sched_task_cb(ctx, false);
> perf_event_swap_task_ctx_data(ctx, next_ctx);
> + perf_event_sync_stat(ctx, next_ctx);
>
> perf_ctx_enable(ctx, false);
>
> @@ -3559,8 +3572,6 @@ perf_event_context_sched_out(struct task_struct *task, struct task_struct *next)
> RCU_INIT_POINTER(next->perf_event_ctxp, ctx);
>
> do_switch = 0;
> -
> - perf_event_sync_stat(ctx, next_ctx);

The commit message gives a very high level summary of the user visible
changes, but it doesn't say what changes have been made to the code to
accomplish it.

I wasn't sure what this move of perf_even_sync_stat() is for, because
it's actually skipped over when nr_stat_read != 0, which is in this new
case?

> }
> raw_spin_unlock(&next_ctx->lock);
> raw_spin_unlock(&ctx->lock);
> @@ -4533,8 +4544,13 @@ static void __perf_event_read(void *info)
> raw_spin_unlock(&ctx->lock);
> }
>
> -static inline u64 perf_event_count(struct perf_event *event)
> +static inline u64 perf_event_count(struct perf_event *event, bool from_sample)

There are only two trues, and 7 existing falses, so you could just add a
new function like perf_event_count_sample(). But I suppose that's a
style thing.

> {
> + if (from_sample && event->attr.inherit &&
> + event->attr.inherit &&
> + (event->attr.sample_type & PERF_SAMPLE_TID)) {

There's something suspicious about this condition with the
event->attr.inherit twice. Should it be && inherit_stat? I don't know if
there's any test that could have caught this, if it's affecting the
existing inherit but not inherit_stat case?

And it's also probably not very helpful at this stage, but if you run
checkpatch.pl on your patches it will point out some of the style issues.