perf: Allow leader sampling on inherited events

As described in commit:
1f9a7268c67f perf: Do not allow optimized switch for non-cloned events
we dont allow optimized switch for non cloned contexts.

There's no need now to check if one of the context is parent of the other in context_equiv function.

Quoted 7 lines · Jiri Olsa

As described in commit:
1f9a7268c67f perf: Do not allow optimized switch for non-cloned events
we dont allow optimized switch for non cloned contexts.

There's no need now to check if one of the context is parent of the other in context_equiv function.

OK, so talk to me about that patch; it looks like you're slowly
reverting: 5a3126d4fe7c ("perf: Fix the perf context switch optimization").

So what exactly is the problem? I'm still jet-lagged and not seeing it.

Quoted 13 lines · Peter Zijlstra

Quoted 7 lines · Jiri Olsa

As described in commit:
1f9a7268c67f perf: Do not allow optimized switch for non-cloned events
we dont allow optimized switch for non cloned contexts.

There's no need now to check if one of the context is parent of the other in context_equiv function.

OK, so talk to me about that patch; it looks like you're slowly
reverting: 5a3126d4fe7c ("perf: Fix the perf context switch optimization").

Quoted 1 line

So what exactly is the problem? I'm still jet-lagged and not seeing it.

the problem is, that we cannot allow non-cloned context to be part of the optimized switch for reasons explained in commit 1f9a7268c67f

Quoted 14 lines · Jiri Olsa

Quoted 13 lines · Peter Zijlstra

Quoted 7 lines · Jiri Olsa

As described in commit:
1f9a7268c67f perf: Do not allow optimized switch for non-cloned events
we dont allow optimized switch for non cloned contexts.

There's no need now to check if one of the context is parent of the other in context_equiv function.

OK, so talk to me about that patch; it looks like you're slowly
reverting: 5a3126d4fe7c ("perf: Fix the perf context switch optimization").

Quoted 5 lines

Quoted 1 line

So what exactly is the problem? I'm still jet-lagged and not seeing it.

the problem is, that we cannot allow non-cloned context to be part of the optimized switch for reasons explained in commit 1f9a7268c67f

The thing is; I don't understand those reasons. That commit log doesn't explain.

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

Quoted 8 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

The exit would remove from the context but leave the event in existence. Both the fd and the inherited events would have references to it, only once those are gone do we destroy the actual event.

Quoted 15 lines · Peter Zijlstra

Quoted 8 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

Quoted 3 lines

The exit would remove from the context but leave the event in existence. Both the fd and the inherited events would have references to it, only once those are gone do we destroy the actual event.

I have another 'problem' with 179033b3e064. What if you 'want' to continue monitoring after the initial task died? Eg. if you want to monitor crap that unconditionally daemonizes.

Quoted 3 lines

I have another 'problem' with 179033b3e064. What if you 'want' to continue monitoring after the initial task died? Eg. if you want to monitor crap that unconditionally daemonizes.

right.. did not think of that.. need to check more, but seems like just the check for children should be enough

---

kernel/events/core.c +13 -0

index bf482ccbdbe1..341d0b47ca14 100644
@@ -3568,6 +3568,19 @@ static int perf_event_read_one(struct perf_event *event,
 	return n * sizeof(u64);
 }
 
+static bool is_event_hup(struct perf_event *event)
+{
+	bool no_children;
+
+	if (event->state != PERF_EVENT_STATE_EXIT)
+		return false;
+
+	mutex_lock(&event->child_mutex);
+	no_children = list_empty(&event->child_list);
+	mutex_unlock(&event->child_mutex);
+	return no_children;
+}
+
 /*
  * Read the performance event - simple non blocking version for now
  */

kernel/events/core.c +1 -1

 	if (count < event->read_size)

@@ -3614,7 +3626,7 @@ static unsigned int perf_poll(struct file *file, poll_table *wait)
 
 	poll_wait(file, &event->waitq, wait);
 
-	if (event->state == PERF_EVENT_STATE_EXIT)
+	if (is_event_hup(event))
 		return events;
 
 	/*

Quoted 11 lines · Peter Zijlstra

Quoted 8 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

Quoted 7 lines

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

The exit would remove from the context but leave the event in existence. Both the fd and the inherited events would have references to it, only once those are gone do we destroy the actual event.

I have another 'problem' with 179033b3e064. What if you 'want' to continue monitoring after the initial task died? Eg. if you want to monitor crap that unconditionally daemonizes.

So at this point I would suggest we revert both 179033b3e064 and 1f9a7268c67f so that the context switch optimization works again for simple 2 task things (pipe-test).

If we re-introduce 179033b3e064 (which I think makes sense) we need to make sure it works with the context switch optimization (we could add perf_event::task I think, it would clean up a few other things iirc) and we'd have to make it conditional so we can still monitor daemons.

Or am I totally missing things again?

Quoted 6 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

Quoted 2 lines

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

The exit would remove from the context but leave the event in existence. Both the fd and the inherited events would have references to it, only once those are gone do we destroy the actual event.

Quoted 11 lines · Peter Zijlstra

Quoted 8 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

Quoted 3 lines

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

hum, I dont think so.. because the perf_remove_from_context set event to PERF_EVENT_STATE_OFF state anyway.. thus making any new cloned events disabled

Quoted 16 lines · Jiri Olsa

Quoted 14 lines · Peter Zijlstra

Quoted 8 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

Quoted 3 lines

hum, I dont think so.. because the perf_remove_from_context set event to PERF_EVENT_STATE_OFF state anyway.. thus making any new cloned events disabled

Urgh, see I knew I was missing something.

Can't we fix that? Lemme check to see what relies on this.

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Jiri Olsa

Quoted 14 lines · Peter Zijlstra

Quoted 8 lines · Peter Zijlstra

Quoted 2 lines

The thing is; I don't understand those reasons. That commit log doesn't explain.

Ah wait, I finally see. I think we want to fix that exit path, not disallow the cloning.

The thing is, by not allowing this optimization simple things like eg. pipe-test say very expensive.

So its 179033b3e064 ("perf: Add PERF_EVENT_STATE_EXIT state for events with exited task") that introduces the problem. Before that things would work correctly afaict.

Quoted 7 lines

Quoted 3 lines

hum, I dont think so.. because the perf_remove_from_context set event to PERF_EVENT_STATE_OFF state anyway.. thus making any new cloned events disabled

Urgh, see I knew I was missing something.

Can't we fix that? Lemme check to see what relies on this.

2e2af50b1fab ("perf_events: Disable events when we detach them")

Seems to be about it. And I think we should solve that differently, but the best I can come up with ties into the event->ctx mess we have in that other thread.

The thing is, IOC_ENABLE/DISABLE and read() and such should act (sanely and) independent from the attached state.

Its just that the whole event->ctx migration mess is making this somewhat hard atm.

So things like perf_event_read() should not only check ctx->is_active but also worry about event->attach_state & PERF_ATTACH_CONTEXT.

Now the biggest problem is that we cannot tell if its a temporary state (move_group / migrate_context) or permanent (exit)...

Urgh

I just noticed that we initialize the child state with base parent state not the real (immediate) parent.. which is what we want IMO

I wonder attached patch could fix the issue mentioned in:
1f9a726 perf: Do not allow optimized switch for non-cloned events

now I need to recall what I used to test this ;-)

---

kernel/events/core.c +2 -1

index e4d6924..561a4ea 100644
@@ -7794,6 +7794,7 @@ inherit_event(struct perf_event *parent_event,
 	      struct perf_event *group_leader,
 	      struct perf_event_context *child_ctx)
 {
+	enum perf_event_active_state parent_state = parent_event->state;
 	struct perf_event *child_event;
 	unsigned long flags;
 

@@ -7827,7 +7828,7 @@ inherit_event(struct perf_event *parent_event,
 	 * not its attr.disabled bit.  We hold the parent's mutex,
 	 * so we won't race with perf_event_{en, dis}able_family.
 	 */
-	if (parent_event->state >= PERF_EVENT_STATE_INACTIVE)
+	if (parent_state >= PERF_EVENT_STATE_INACTIVE)
 		child_event->state = PERF_EVENT_STATE_INACTIVE;
 	else
 		child_event->state = PERF_EVENT_STATE_OFF;

now I need to recall what I used to test this ;-)

Quoted 3 lines · Jiri Olsa

now I need to recall what I used to test this ;-)

Hint, if you'd mentioned that in the changelog.... :-)

From dc1068c627b332b2a5feb4deedfd96db8e056b5f Mon Sep 17 00:00:00 2001

The optimized task context switch for cloned perf events just swaps whole perf event contexts (of current and next process) if it finds them suitable. Events from the 'current' context will now measure data of the 'next' context and vice versa.

This is ok for cases where we are not directly interested in the event->count value of separate child events, like:
- standard sampling, where we take 'period' value for the event count
- counting, where we accumulate all events (children) into a single count value

But in case we read event by using the PERF_SAMPLE_READ sample type, we are interested in direct event->count value measured in specific task. Switching events within tasks for this kind of measurements corrupts data.

Fixing this by setting/unsetting pin_count for perf event context once cloned event with PERF_SAMPLE_READ read is added/removed. The pin_count value != 0 makes the context not suitable for optimized switch.

Quoted 17 lines · Jiri Olsa

The optimized task context switch for cloned perf events just swaps whole perf event contexts (of current and next process) if it finds them suitable. Events from the 'current' context will now measure data of the 'next' context and vice versa.

This is ok for cases where we are not directly interested in the event->count value of separate child events, like:
- standard sampling, where we take 'period' value for the event count
- counting, where we accumulate all events (children) into a single count value

But in case we read event by using the PERF_SAMPLE_READ sample type, we are interested in direct event->count value measured in specific task. Switching events within tasks for this kind of measurements corrupts data.

Quoted 4 lines

Fixing this by setting/unsetting pin_count for perf event context once cloned event with PERF_SAMPLE_READ read is added/removed. The pin_count value != 0 makes the context not suitable for optimized switch.

no.. so the value of the counter is the sum of all the inherited events. It doesn't matter if you flip it or not the sum is not affected.

PERF_SAMPLE_READ should return the value.

Quoted 4 lines

no.. so the value of the counter is the sum of all the inherited events. It doesn't matter if you flip it or not the sum is not affected.

PERF_SAMPLE_READ should return the value.

so I want to be able to do the leader sampling over child processes that means:
- have event group with sampling leader, and the rest of the group events' periods being read on leader's sample via PERF_SAMPLE_READ sample_type
- for each child process created I want it to do the same thing as the parent - sample on leader, read values of other events in group via PERF_SAMPLE_READ

Quoted 5 lines · Jiri Olsa

Quoted 4 lines

no.. so the value of the counter is the sum of all the inherited events. It doesn't matter if you flip it or not the sum is not affected.

PERF_SAMPLE_READ should return the value.

Quoted 8 lines

so I want to be able to do the leader sampling over child processes that means:
- have event group with sampling leader, and the rest of the group events' periods being read on leader's sample via PERF_SAMPLE_READ sample_type
- for each child process created I want it to do the same thing as the parent - sample on leader, read values of other events in group via PERF_SAMPLE_READ

The thing is, PERF_SAMPLE_READ should return the exact same thing as an actual read(), and for read() the value reported is the sum of all events.

I _think_ I know what you want, and I think I see why you'd want that, but I'm not sure how to best do that.. Hmm.. maybe look at 'perf_event_attr::inherit_stat' that appears to be similar.

At which point read() vs inherit_stat might be 'broken'. Hard to know if anybody uses that :-(

Adding period data column to be displayed in perf script. It's possible to get period values using -f option, like:

   $ perf script -f comm,tid,time,period,ip,sym,dso
           :26019 26019 52414.329088:       3707  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
           :26019 26019 52414.329088:         44  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
           :26019 26019 52414.329093:       1987  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
           :26019 26019 52414.329093:          6  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
               ls 26019 52414.329442:     537558        3407c0639c _dl_map_object_from_fd (/usr/lib64/ld-2.17.so)
               ls 26019 52414.329442:       2099        3407c0639c _dl_map_object_from_fd (/usr/lib64/ld-2.17.so)
               ls 26019 52414.330181:    1242100        34080917bb get_next_seq (/usr/lib64/libc-2.17.so)
               ls 26019 52414.330181:       3774        34080917bb get_next_seq (/usr/lib64/libc-2.17.so)
               ls 26019 52414.331427:    1083662  ffffffff810c7dc2 update_curr ([kernel.kallsyms])
               ls 26019 52414.331427:        360  ffffffff810c7dc2 update_curr ([kernel.kallsyms])

Cc Andi Kleen <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Corey Ashford <[email protected]>

Cc David Ahern <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Jen-Cheng(Tommy) Huang <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Paul Mackerras <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Stephane Eranian <[email protected]>

Signed-off-by Jiri Olsa <[email protected]>

---
  tools/perf/Documentation/perf-script.txt |  2 +-
  tools/perf/builtin-script.c              | 12 +++++++++++-
  2 files changed, 12 insertions(+), 2 deletions(-)

Quoted 27 lines · Jiri Olsa

Adding period data column to be displayed in perf script. It's possible to get period values using -f option, like:

  $ perf script -f comm,tid,time,period,ip,sym,dso
          :26019 26019 52414.329088:       3707  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
          :26019 26019 52414.329088:         44  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
          :26019 26019 52414.329093:       1987  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
          :26019 26019 52414.329093:          6  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
              ls 26019 52414.329442:     537558        3407c0639c _dl_map_object_from_fd (/usr/lib64/ld-2.17.so)
              ls 26019 52414.329442:       2099        3407c0639c _dl_map_object_from_fd (/usr/lib64/ld-2.17.so)
              ls 26019 52414.330181:    1242100        34080917bb get_next_seq (/usr/lib64/libc-2.17.so)
              ls 26019 52414.330181:       3774        34080917bb get_next_seq (/usr/lib64/libc-2.17.so)
              ls 26019 52414.331427:    1083662  ffffffff810c7dc2 update_curr ([kernel.kallsyms])
              ls 26019 52414.331427:        360  ffffffff810c7dc2 update_curr ([kernel.kallsyms])

Cc Andi Kleen <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Corey Ashford <[email protected]>

Cc David Ahern <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Jen-Cheng(Tommy) Huang <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Paul Mackerras <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Stephane Eranian <[email protected]>

Signed-off-by Jiri Olsa <[email protected]>

Quoted 4 lines

---
 tools/perf/Documentation/perf-script.txt |  2 +-
 tools/perf/builtin-script.c              | 12 +++++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

Acked-by David Ahern <[email protected]>

Quoted 33 lines · Jiri Olsa

Quoted 31 lines

Adding period data column to be displayed in perf script. It's possible to get period values using -f option, like:

  $ perf script -f comm,tid,time,period,ip,sym,dso
          :26019 26019 52414.329088:       3707  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
          :26019 26019 52414.329088:         44  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
          :26019 26019 52414.329093:       1987  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
          :26019 26019 52414.329093:          6  ffffffff8105443a native_write_msr_safe ([kernel.kallsyms])
              ls 26019 52414.329442:     537558        3407c0639c _dl_map_object_from_fd (/usr/lib64/ld-2.17.so)
              ls 26019 52414.329442:       2099        3407c0639c _dl_map_object_from_fd (/usr/lib64/ld-2.17.so)
              ls 26019 52414.330181:    1242100        34080917bb get_next_seq (/usr/lib64/libc-2.17.so)
              ls 26019 52414.330181:       3774        34080917bb get_next_seq (/usr/lib64/libc-2.17.so)
              ls 26019 52414.331427:    1083662  ffffffff810c7dc2 update_curr ([kernel.kallsyms])
              ls 26019 52414.331427:        360  ffffffff810c7dc2 update_curr ([kernel.kallsyms])

Cc Andi Kleen <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Corey Ashford <[email protected]>

Cc David Ahern <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Jen-Cheng(Tommy) Huang <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Paul Mackerras <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Stephane Eranian <[email protected]>

Signed-off-by Jiri Olsa <[email protected]>

---
 tools/perf/Documentation/perf-script.txt |  2 +-
 tools/perf/builtin-script.c              | 12 +++++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

Quoted 1 line

Acked-by David Ahern <[email protected]>

Arnaldo,
could you please pick this one and patch 9/9?
just realized this was left behind ;-)

Adding period as a default output column in script command fo hardware, software and raw events.

If PERF_SAMPLE_PERIOD sample type is defined in perf.data, following will be displayed in perf script output:

   $ perf script
               ls  8034 57477.887209:     250000 task-clock:  ffffffff81361d72 memset ([kernel.kallsyms])
               ls  8034 57477.887464:     250000 task-clock:  ffffffff816f6d92 _raw_spin_unlock_irqrestore ([kernel.kallsyms])
               ls  8034 57477.887708:     250000 task-clock:  ffffffff811a94f0 do_munmap ([kernel.kallsyms])
               ls  8034 57477.887959:     250000 task-clock:        34080916c6 get_next_seq (/usr/lib64/libc-2.17.so)
               ls  8034 57477.888208:     250000 task-clock:        3408079230 _IO_doallocbuf (/usr/lib64/libc-2.17.so)
               ls  8034 57477.888717:     250000 task-clock:  ffffffff814242c8 n_tty_write ([kernel.kallsyms])
               ls  8034 57477.889285:     250000 task-clock:        3408076402 fwrite_unlocked (/usr/lib64/libc-2.17.so)

Cc Andi Kleen<[email protected]>

Cc Arnaldo Carvalho de Melo<[email protected]>

Cc Corey Ashford<[email protected]>

Cc David Ahern<[email protected]>

Cc Frederic Weisbecker<[email protected]>

Cc Ingo Molnar<[email protected]>

Cc Jen-Cheng(Tommy) Huang<[email protected]>

Cc Namhyung Kim<[email protected]>

Cc Paul Mackerras<[email protected]>

Cc Peter Zijlstra<[email protected]>

Cc Stephane Eranian<[email protected]>

Signed-off-by Jiri Olsa<[email protected]>

Quoted 15 lines · Jiri Olsa

Adding period as a default output column in script command fo hardware, software and raw events.

If PERF_SAMPLE_PERIOD sample type is defined in perf.data, following will be displayed in perf script output:

  $ perf script
              ls  8034 57477.887209:     250000 task-clock:  ffffffff81361d72 memset ([kernel.kallsyms])
              ls  8034 57477.887464:     250000 task-clock:  ffffffff816f6d92 _raw_spin_unlock_irqrestore ([kernel.kallsyms])
              ls  8034 57477.887708:     250000 task-clock:  ffffffff811a94f0 do_munmap ([kernel.kallsyms])
              ls  8034 57477.887959:     250000 task-clock:        34080916c6 get_next_seq (/usr/lib64/libc-2.17.so)
              ls  8034 57477.888208:     250000 task-clock:        3408079230 _IO_doallocbuf (/usr/lib64/libc-2.17.so)
              ls  8034 57477.888717:     250000 task-clock:  ffffffff814242c8 n_tty_write ([kernel.kallsyms])
              ls  8034 57477.889285:     250000 task-clock:        3408076402 fwrite_unlocked (/usr/lib64/libc-2.17.so)

Quoted 12 lines

Cc Andi Kleen<[email protected]>

Cc Arnaldo Carvalho de Melo<[email protected]>

Cc Corey Ashford<[email protected]>

Cc David Ahern<[email protected]>

Cc Frederic Weisbecker<[email protected]>

Cc Ingo Molnar<[email protected]>

Cc Jen-Cheng(Tommy) Huang<[email protected]>

Cc Namhyung Kim<[email protected]>

Cc Paul Mackerras<[email protected]>

Cc Peter Zijlstra<[email protected]>

Cc Stephane Eranian<[email protected]>

Signed-off-by Jiri Olsa<[email protected]>

Acked-by David Ahern <[email protected]>

hi,
Jen-Cheng(Tommy) Huang reported the leader sampling not working on children processes:
http://www.mail-archive.com/[email protected]/msg01644.html

The leader sampling (example below) lets the group leader event (cycles) do the sampling and reads the rest of the group (cache-misses) via PERF_FORMAT_GROUP format.

Example:

  $ perf record -e '{cycles,cache-misses}:S' <workload>
  $ perf report --group

The perf report --group allows to see all events group data in single view.

The reason for leader sampling being switched off for inherited events, is that the kernel does no allow PERF_FORMAT_GROUP format on inherited events (which is used by leader sampling).

I switched on the PERF_FORMAT_GROUP format for inherited events with few other fixies in patches:
perf: Deny optimized switch for events read by PERF_SAMPLE_READ
perf: Allow PERF_FORMAT_GROUP format on inherited events

And I fixed perf tool code to be able to process data from children processes.

Anyway, I might have missed some other reason why this was never switched on in kernel, so sending this as RFC.

v2 changes:
- detection of the kernel support
- added perf script support for period column
- separate kernel change for context_equiv change