Messages in this thread Patches in this message | | | Date | Tue, 30 May 2017 11:45:12 +0200 | From | Peter Zijlstra <> | Subject | Re: perf group read for inherited events |
| |
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))
| |