Messages in this thread | | | Subject | Re: [PATCH V7 07/14] perf/core: Add a new PERF_EV_CAP_COEXIST event capability | From | "Liang, Kan" <> | Date | Fri, 24 Jul 2020 10:19:25 -0400 |
| |
On 7/24/2020 9:54 AM, Peter Zijlstra wrote: > On Fri, Jul 24, 2020 at 09:43:44AM -0400, Liang, Kan wrote: >> >> >> On 7/24/2020 7:46 AM, peterz@infradead.org wrote: >>> On Fri, Jul 24, 2020 at 12:55:43PM +0200, peterz@infradead.org wrote: >>>>> + event_sched_out(event, cpuctx, ctx); >>>>> + perf_event_set_state(event, PERF_EVENT_STATE_ERROR); >>>>> +} >>>> >>>> Ah, so the problem here is that ERROR is actually recoverable using >>>> IOC_ENABLE. We don't want that either. Let me try and figure out of EXIT >>>> would work. >>> >>> EXIT is difficult too.. Also, that COEXIST thing hurt my brian, can't we >>> do a simpler SIBLING thing that simply requires the event to be a group >>> sibling? >>> >>> The consequence is that SLOTS must be the leader, is that really a >>> problem? You keep providing the {cycles, slots, metric-things} example, >>> but afaict {slots, metric-thing, cycles} should work just fine too. >>> PERF_SAMPLE_READ with PERF_FORMAT_GROUP doesn't need to the the leader. >> >> I'm not sure I get your point. >> For the PERF_SAMPLE_READ with PERF_FORMAT_GROUP case, other events can be >> the leader, e.g., {cycles, slots, metric-things}:S. >> In this case, the SLOTS event is not a leader. I don't think we can assume >> that the SLOTS event must be the leader. > > You can have a sibling event with SAMPLE_READ and FORMAT_GROUP just > fine. The sampling event doesn't need to be the leader. >
There will be a problem for the current perf tool, which assumes that the leader event is the sampling event.
I will check how can we specially handle it in the perf tool.
Thanks, Kan
| |