Re: [PATCH v2]: perf/core: addressing 4x slowdown during per-process, profiling of STREAM benchmark on Intel Xeon Phi

Alexey Budankov
2017-05-29T10:56:15Z

On 29.05.2017 13:43, Peter Zijlstra wrote:
> On Mon, May 29, 2017 at 12:15:14PM +0300, Alexey Budankov wrote:
>> On 29.05.2017 10:46, Peter Zijlstra wrote:
>>> On Sat, May 27, 2017 at 02:19:51PM +0300, Alexey Budankov wrote:
>
>>>> @@ -742,7 +772,17 @@ struct perf_event_context {
>>>>
>>>> struct list_head active_ctx_list;
>>>> struct list_head pinned_groups;
>>>> + /*
>>>> + * Cpu tree for pinned groups; keeps event's group_node nodes
>>>> + * of attached flexible groups;
>>>> + */
>>>> + struct rb_root pinned_tree;
>>>> struct list_head flexible_groups;
>>>> + /*
>>>> + * Cpu tree for flexible groups; keeps event's group_node nodes
>>>> + * of attached flexible groups;
>>>> + */
>>>> + struct rb_root flexible_tree;
>>>> struct list_head event_list;
>>>> int nr_events;
>>>> int nr_active;
>>>> @@ -758,6 +798,7 @@ struct perf_event_context {
>>>> */
>>>> u64 time;
>>>> u64 timestamp;
>>>> + struct perf_event_tstamp tstamp_data;
>>>>
>>>> /*
>>>> * These fields let us detect when two contexts have both
>>>
>>>
>>> So why do we now have a list _and_ a tree for the same entries?
>
>> We need groups list to iterate through all groups configured for collection
>> and we need the tree to quickly iterate through the groups allocated for a
>> particular CPU only.
>
> *confused*, what?
>
> Why can't the tree do both?
>

Well, indeed, the tree provides such capability too. However switching
to the full tree iteration in cases where we now go through _groups
lists will enlarge the patch, what is probably is not a big deal. Do you
think it is worth implementing the switch?

Thanks,
Alexey