All of lore.kernel.org
 help / color / mirror / Atom feed
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



      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.