[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ce9cd541-04ba-4ed5-9d36-3f2ecd95d484@linux.intel.com>
Date: Wed, 21 May 2025 09:55:37 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, namhyung@...nel.org, irogers@...gle.com,
mark.rutland@....com, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, eranian@...gle.com, ctshao@...gle.com,
tmricht@...ux.ibm.com, leo.yan@....com
Subject: Re: [PATCH V4 02/16] perf: Only dump the throttle log for the leader
On 2025-05-21 8:05 a.m., Peter Zijlstra wrote:
> On Tue, May 20, 2025 at 11:16:30AM -0700, kan.liang@...ux.intel.com wrote:
>> From: Kan Liang <kan.liang@...ux.intel.com>
>>
>> The PERF_RECORD_THROTTLE records are dumped for all throttled events.
>> It's not necessary for group events, which are throttled altogether.
>>
>> Optimize it by only dump the throttle log for the leader.
>>
>> The sample right after the THROTTLE record must be generated by the
>> actual target event. It is good enough for the perf tool to locate the
>> actual target event.
>
> So while both patches change behaviour; the first patch should preserve
> all that was done and simply do more. OTOH this patch explicitly changes
> behaviour in that what was done, is now no longer done.
>
> Are we very sure there isn't a tool that expect per event throttle
> messages?
>
For a non-group event, the behavior is not changed. The event throttle
message is dumped for each of them, because the leader is itself.
The second patch may only change the behavior of some cases of the group
events, but not all of them. For example, the behavior of the common
usage sampling read case is not changed, since the leader is the
sampling event.
Also, as far as I know, the current perf tool doesn't track which event
is throttled.
Furthermore, the group events were broken. I doubt there are other tools
really work with group events throttle message.
All in all, we don't lose the throttle information for each event. Based
on the current information, tools can reconstruct it. Since the tool
needs to be fixed anyway, I don't see a problem.
Thanks,
Kan
Powered by blists - more mailing lists