From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, acme@kernel.org, namhyung@kernel.org,
irogers@google.com, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, ak@linux.intel.com,
eranian@google.com, dapeng1.mi@linux.intel.com
Subject: Re: [PATCH V6 3/3] perf/x86/intel: Support PEBS counters snapshotting
Date: Fri, 3 Jan 2025 11:15:26 -0500 [thread overview]
Message-ID: <5005ace4-6432-41d4-8b36-47ae3d851552@linux.intel.com> (raw)
In-Reply-To: <20241220142221.GN11133@noisy.programming.kicks-ass.net>
Hi Peter,
Sorry for the late response. I was on vacation.
On 2024-12-20 9:22 a.m., Peter Zijlstra wrote:
> On Wed, Dec 18, 2024 at 07:16:43AM -0800, kan.liang@linux.intel.com wrote:
>
>> @@ -3109,6 +3116,27 @@ static int handle_pmi_common(struct pt_regs *regs, u64 status)
>> if (!test_bit(bit, cpuc->active_mask))
>> continue;
>>
>
>> + if (is_pebs_counter_event(event))
>> + x86_pmu.drain_pebs(regs, &data);
>> +
>> if (!intel_pmu_save_and_restart(event))
>> continue;
>>
>> @@ -4056,6 +4084,23 @@ static int intel_pmu_hw_config(struct perf_event *event)
>> event->hw.flags |= PERF_X86_EVENT_PEBS_VIA_PT;
>> }
>>
>> + if ((event->attr.sample_type & PERF_SAMPLE_READ) &&
>> + (x86_pmu.intel_cap.pebs_format >= 6)) {
>
> Right, so the event that has SAMPLE_READ on is 'event'
>
>> + struct perf_event *leader = event->group_leader;
>> + bool slots_leader = is_slots_event(leader);
>> +
>> + if (slots_leader)
>> + leader = list_next_entry(leader, sibling_list);
>
> Uh, what, why?
This was to specially handle the perf metric topdown group.
>
>> +
>> + if (leader->attr.precise_ip) {
>> + event->hw.flags |= PERF_X86_EVENT_PEBS_CNTR;
>> + if (slots_leader) {
>> + leader->hw.flags |= PERF_X86_EVENT_PEBS_CNTR;
>> + event->group_leader->hw.flags |= PERF_X86_EVENT_PEBS_CNTR;
>> + }
>> + }
>
> And this is more confusion. You want event to be a PEBS event, not the
> leader, you don't care about the leader.
Right
> >
>> + }
>> +
>> if ((event->attr.type == PERF_TYPE_HARDWARE) ||
>> (event->attr.type == PERF_TYPE_HW_CACHE))
>> return 0;
>
>> +static inline bool is_pebs_counter_event(struct perf_event *event)
>> +{
>> + return event->hw.flags & PERF_X86_EVENT_PEBS_CNTR;
>> +}
>
> For that drain_pebs() thing, you want all group members to have
> PEBS_CNTR set.
>
> That is, if PEBS>=6 and event is PEBS and event has SAMPLE_READ, then
> mark the whole group with PEBS_CNTR
Yes, that was the design.
>
> SAMPLE_READ doesn't particularly care who's the leader, the event that
> has SAMPLE_READ will read the whole group. Heck they could all have
> SAMPLE_READ and then all their samples will read each-other.
Right. It should be good enough to only set the flag for the
event->group_leader, since there is only one sampling event for a
SAMPLE_READ group.
The hw_config check can be simplified as below.
if ((event->attr.sample_type & PERF_SAMPLE_READ) &&
(x86_pmu.intel_cap.pebs_format >= 6) &&
is_sampling_event(event) &&
event->attr.precise_ip)
event->group_leader->hw.flags |= PERF_X86_EVENT_PEBS_CNTR;
Also, Only need to check the leader's flag to indicate the event in a
SAMPLE_READ group.
-static inline bool is_pebs_counter_event(struct perf_event *event)
+static inline bool is_pebs_counter_event_group(struct perf_event *event)
{
- return event->hw.flags & PERF_X86_EVENT_PEBS_CNTR;
+ return event->group_leader->hw.flags & PERF_X86_EVENT_PEBS_CNTR;
}
Thanks,
Kan
prev parent reply other threads:[~2025-01-03 16:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-18 15:16 [PATCH V6 1/3] perf/x86/intel/ds: Add PEBS format 6 kan.liang
2024-12-18 15:16 ` [PATCH V6 2/3] perf: Extend perf_output_read kan.liang
2024-12-19 22:21 ` Peter Zijlstra
2024-12-20 0:42 ` Liang, Kan
2024-12-18 15:16 ` [PATCH V6 3/3] perf/x86/intel: Support PEBS counters snapshotting kan.liang
2024-12-18 16:32 ` Peter Zijlstra
2024-12-18 16:55 ` Liang, Kan
2024-12-18 17:01 ` Peter Zijlstra
2024-12-20 14:22 ` Peter Zijlstra
2025-01-03 16:15 ` Liang, Kan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5005ace4-6432-41d4-8b36-47ae3d851552@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®