Re: perf group read for inherited events

[Peter Zijlstra]

On Fri, May 26, 2017 at 01:56:01PM -0700, Andi Kleen wrote:

> I have a need for read group reads for inherited events.
> 
> It looks like the perf group read code already has all the code
> to handle inheritance, __perf_read_group_add walks
> the children list and adds them all up.
> 
>    4409 
>    4410         list_for_each_entry(sub, &leader->sibling_list, group_entry) {
>    4411                 values[n++] += perf_event_count(sub);
>    4412                 if (read_format & PERF_FORMAT_ID)
>    4413                         values[n++] = primary_event_id(sub);
>    4414         }
> 
> 
> I disabled the check that forbids this and it seems to work
> from some simple testing.
> 
> Again do I miss something why this was disabled?

The thing that seems difficult is PERF_SAMPLE_READ vs inherited,
irrespective of PERF_FORMAT_GROUP.

The error seems to be in that patch you fingered:

  3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")


-       PERF_SAMPLE_GROUP                       = 1U << 4,
+       PERF_SAMPLE_READ                        = 1U << 4,

-       if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP))
+       if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))

is a clear fail :/

> Perhaps some locking issue? There are some comments on it,
> but I'm not sure I understand all the subtleties:
> 
>         /*
>          * By locking the child_mutex of the leader we effectively
>          * lock the child list of all siblings.. XXX explain how.
>          */
>         mutex_lock(&leader->child_mutex);

This is more recent. Here I failed to find a coherent text to explain
the locking. It is correct through. I think its something like:

@@ -4426,8 +4426,9 @@ static int perf_read_group(struct perf_event *event,
 	values[0] = 1 + leader->nr_siblings;
 
 	/*
-	 * By locking the child_mutex of the leader we effectively
-	 * lock the child list of all siblings.. XXX explain how.
+	 * By locking the child_mutex of the leader we effectively lock the
+	 * child list of all siblings. Since inherit_group() will first clone
+	 * the leader and will this be blocked on us holding its child_mutex.
 	 */
 	mutex_lock(&leader->child_mutex);
 

> Or is the simple patch below good enough?

The below seems to be the correct thing. It is rather unfortunate that
this would break/significantly change existing semantics :/

---
 kernel/events/core.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 8d6acaeeea17..2d9de6fb9a5a 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5722,9 +5722,6 @@ static void perf_output_read_one(struct perf_output_handle *handle,
 	__output_copy(handle, values, n * sizeof(u64));
 }
 
-/*
- * XXX PERF_FORMAT_GROUP vs inherited events seems difficult.
- */
 static void perf_output_read_group(struct perf_output_handle *handle,
 			    struct perf_event *event,
 			    u64 enabled, u64 running)
@@ -5769,6 +5766,12 @@ static void perf_output_read_group(struct perf_output_handle *handle,
 #define PERF_FORMAT_TOTAL_TIMES (PERF_FORMAT_TOTAL_TIME_ENABLED|\
 				 PERF_FORMAT_TOTAL_TIME_RUNNING)
 
+/*
+ * XXX PERF_SAMPLE_READ vs inherited events seems difficult.
+ *
+ * The problem is that its both hard and excessively expensive to iterate the
+ * child list from interrupt/NMI context.
+ */
 static void perf_output_read(struct perf_output_handle *handle,
 			     struct perf_event *event)
 {
@@ -9434,9 +9437,10 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
 	local64_set(&hwc->period_left, hwc->sample_period);
 
 	/*
-	 * we currently do not support PERF_FORMAT_GROUP on inherited events
+	 * We currently do not support PERF_SAMPLE_READ on inherited events.
+	 * See perf_output_read().
 	 */
-	if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))
+	if (attr->inherit && (attr->sample_type & PERF_SAMPLE_READ))
 		goto err_ns;
 
 	if (!has_branch_stack(event))