[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6803478E-035D-4CD4-B16E-6250BB07CA0B@fb.com>
Date: Mon, 1 Oct 2018 23:25:09 +0000
From: Song Liu <songliubraving@...com>
To: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
CC: lkml <linux-kernel@...r.kernel.org>,
Kernel Team <Kernel-team@...com>, Tejun Heo <tj@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Olsa <jolsa@...nel.org>,
Alexey Budankov <alexey.budankov@...ux.intel.com>,
"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>
Subject: Re: [PATCH v3 1/1] perf: Sharing PMU counters across compatible
events
> On Sep 27, 2018, at 9:53 PM, Song Liu <songliubraving@...com> wrote:
>
> Hi Ravi,
>
>> On Sep 27, 2018, at 9:33 PM, Ravi Bangoria <ravi.bangoria@...ux.ibm.com> wrote:
>>
>> Hi Song,
>>
>> On 09/25/2018 03:55 AM, Song Liu wrote:
>>> This patch tries to enable PMU sharing. To make perf event scheduling
>>> fast, we use special data structures.
>>>
>>> An array of "struct perf_event_dup" is added to the perf_event_context,
>>> to remember all the duplicated events under this ctx. All the events
>>> under this ctx has a "dup_id" pointing to its perf_event_dup. Compatible
>>> events under the same ctx share the same perf_event_dup. The following
>>> figure shows a simplified version of the data structure.
>>>
>>> ctx -> perf_event_dup -> master
>>> ^
>>> |
>>> perf_event /|
>>> |
>>> perf_event /
>>>
>>
>> I've not gone through the patch in detail, but I was specifically
>> interested in scenarios where one perf instance is counting event
>> systemwide and thus other perf instance fails to count the same
>> event for a specific workload because that event can be counted
>> in one hw counter only.
>>
>> Ex: https://lkml.org/lkml/2018/3/12/1011
>>
>> Seems this patch does not solve this issue. Please let me know if
>> I'm missing anything.
>>
>
> In this case, unfortunately, these two events cannot share the same
> counter, because one of them is in cpu ctx; while the other belongs
> to the task ctx. They have to go through the rotation, that each
> event counts 50% of the time. However, if you have 2 events in cpu
> ctx and 2 events in task ctx on the same counter, this patch will
> help each event to count 50% of time, instead of 25%.
I was wrong here. The CPU flexible events have higher priority than
task flexible events, so the per task event will never get scheduled.
On the other hand, I think it is possible to put per task event on
per CPU ctx, and handle the event just like per cgroup events. Once we
get this part work, system wide events will be able to share PMU with
per task events. Let me try prototype it.
Thanks,
Song
Powered by blists - more mailing lists