public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Eranian Stephane <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [PATCH 11/20] perf/x86/intel: Setup PEBS constraints base on counter & pdist map
Date: Thu, 6 Feb 2025 10:47:26 +0800	[thread overview]
Message-ID: <1338dd77-e9c1-4eac-9d0f-195829acdd2a@linux.intel.com> (raw)
In-Reply-To: <f198c454-ff7c-42eb-80f8-45bc4b94210d@linux.intel.com>


On 1/28/2025 12:07 AM, Liang, Kan wrote:
>
> On 2025-01-23 9:07 a.m., Dapeng Mi wrote:
>> arch-PEBS provides CPUIDs to enumerate which counters support PEBS
>> sampling and precise distribution PEBS sampling. Thus PEBS constraints
>> can be dynamically configured base on these counter and precise
>> distribution bitmap instead of defining them statically.
>>
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> ---
>>  arch/x86/events/intel/core.c | 20 ++++++++++++++++++++
>>  arch/x86/events/intel/ds.c   |  1 +
>>  2 files changed, 21 insertions(+)
>>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 7775e1e1c1e9..0f1be36113fa 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -3728,6 +3728,7 @@ intel_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
>>  			    struct perf_event *event)
>>  {
>>  	struct event_constraint *c1, *c2;
>> +	struct pmu *pmu = event->pmu;
>>  
>>  	c1 = cpuc->event_constraint[idx];
>>  
>> @@ -3754,6 +3755,25 @@ intel_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
>>  		c2->weight = hweight64(c2->idxmsk64);
>>  	}
>>  
>> +	if (x86_pmu.arch_pebs && event->attr.precise_ip) {
>> +		u64 pebs_cntrs_mask;
>> +		u64 cntrs_mask;
>> +
>> +		if (event->attr.precise_ip >= 3)
>> +			pebs_cntrs_mask = hybrid(pmu, arch_pebs_cap).pdists;
>> +		else
>> +			pebs_cntrs_mask = hybrid(pmu, arch_pebs_cap).counters;
>> +
>> +		cntrs_mask = hybrid(pmu, fixed_cntr_mask64) << INTEL_PMC_IDX_FIXED |
>> +			     hybrid(pmu, cntr_mask64);
>> +
>> +		if (pebs_cntrs_mask != cntrs_mask) {
>> +			c2 = dyn_constraint(cpuc, c2, idx);
>> +			c2->idxmsk64 &= pebs_cntrs_mask;
>> +			c2->weight = hweight64(c2->idxmsk64);
>> +		}
>> +	}
> The pebs_cntrs_mask and cntrs_mask wouldn't be changed since the machine
> boot. I don't think it's efficient to calculate them every time.
>
> Maybe adding a local pebs_event_constraints_pdist[] and update both
> pebs_event_constraints[] and pebs_event_constraints_pdist[] with the
> enumerated mask at initialization time.
>
> Update the intel_pebs_constraints() to utilize the corresponding array
> according to the precise_ip.
>
> The above may be avoided.

Even we have these two arrays, we still need the dynamic constraint, right?
We can't predict what the event is, the event may be mapped to a quite
specific event constraint and we can know it in advance.


>
> Thanks,
> Kan
>
>> +
>>  	return c2;
>>  }
>>  
>> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
>> index 2f2c6b7c801b..a573ce0e576a 100644
>> --- a/arch/x86/events/intel/ds.c
>> +++ b/arch/x86/events/intel/ds.c
>> @@ -2941,6 +2941,7 @@ static void __init intel_arch_pebs_init(void)
>>  	x86_pmu.pebs_buffer_size = PEBS_BUFFER_SIZE;
>>  	x86_pmu.drain_pebs = intel_pmu_drain_arch_pebs;
>>  	x86_pmu.pebs_capable = ~0ULL;
>> +	x86_pmu.flags |= PMU_FL_PEBS_ALL;
>>  }
>>  
>>  /*

  reply	other threads:[~2025-02-06  2:47 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-23 14:07 [PATCH 00/20] Arch-PEBS and PMU supports for Clearwater Forest Dapeng Mi
2025-01-23 14:07 ` [PATCH 01/20] perf/x86/intel: Add PMU support " Dapeng Mi
2025-01-27 16:26   ` Peter Zijlstra
2025-02-06  1:31     ` Mi, Dapeng
2025-02-06  7:53       ` Peter Zijlstra
2025-02-06  9:35         ` Mi, Dapeng
2025-02-06  9:39           ` Peter Zijlstra
2025-01-23 14:07 ` [PATCH 02/20] perf/x86/intel: Fix ARCH_PERFMON_NUM_COUNTER_LEAF Dapeng Mi
2025-01-27 16:29   ` Peter Zijlstra
2025-01-27 16:43     ` Liang, Kan
2025-01-27 21:29       ` Peter Zijlstra
2025-01-28  0:28         ` Liang, Kan
2025-01-23 14:07 ` [PATCH 03/20] perf/x86/intel: Parse CPUID archPerfmonExt leaves for non-hybrid CPUs Dapeng Mi
2025-01-23 18:58   ` Andi Kleen
2025-01-27 15:19     ` Liang, Kan
2025-01-27 16:44       ` Peter Zijlstra
2025-02-06  2:09         ` Mi, Dapeng
2025-01-23 14:07 ` [PATCH 04/20] perf/x86/intel: Decouple BTS initialization from PEBS initialization Dapeng Mi
2025-01-23 14:07 ` [PATCH 05/20] perf/x86/intel: Rename x86_pmu.pebs to x86_pmu.ds_pebs Dapeng Mi
2025-01-23 14:07 ` [PATCH 06/20] perf/x86/intel: Initialize architectural PEBS Dapeng Mi
2025-01-28 11:22   ` Peter Zijlstra
2025-02-06  2:25     ` Mi, Dapeng
2025-01-23 14:07 ` [PATCH 07/20] perf/x86/intel/ds: Factor out common PEBS processing code to functions Dapeng Mi
2025-01-23 14:07 ` [PATCH 08/20] perf/x86/intel: Process arch-PEBS records or record fragments Dapeng Mi
2025-01-23 14:07 ` [PATCH 09/20] perf/x86/intel: Factor out common functions to process PEBS groups Dapeng Mi
2025-01-23 14:07 ` [PATCH 10/20] perf/x86/intel: Allocate arch-PEBS buffer and initialize PEBS_BASE MSR Dapeng Mi
2025-01-23 14:07 ` [PATCH 11/20] perf/x86/intel: Setup PEBS constraints base on counter & pdist map Dapeng Mi
2025-01-27 16:07   ` Liang, Kan
2025-02-06  2:47     ` Mi, Dapeng [this message]
2025-02-06 15:01       ` Liang, Kan
2025-02-07  1:27         ` Mi, Dapeng
2025-01-23 14:07 ` [PATCH 12/20] perf/x86/intel: Setup PEBS data configuration and enable legacy groups Dapeng Mi
2025-01-23 14:07 ` [PATCH 13/20] perf/x86/intel: Add SSP register support for arch-PEBS Dapeng Mi
2025-01-24  5:16   ` Andi Kleen
2025-01-27 15:38     ` Liang, Kan
2025-01-23 14:07 ` [PATCH 14/20] perf/x86/intel: Add counter group " Dapeng Mi
2025-01-23 14:07 ` [PATCH 15/20] perf/core: Support to capture higher width vector registers Dapeng Mi
2025-01-23 14:07 ` [PATCH 16/20] perf/x86/intel: Support arch-PEBS vector registers group capturing Dapeng Mi
2025-01-23 14:07 ` [PATCH 17/20] perf tools: Support to show SSP register Dapeng Mi
2025-01-23 16:15   ` Ian Rogers
2025-02-06  2:57     ` Mi, Dapeng
2025-01-23 14:07 ` [PATCH 18/20] perf tools: Support to capture more vector registers (common part) Dapeng Mi
2025-01-23 16:42   ` Ian Rogers
2025-01-27 15:50     ` Liang, Kan
2025-02-06  3:12       ` Mi, Dapeng
2025-01-23 14:07 ` [PATCH 19/20] perf tools: Support to capture more vector registers (x86/Intel part) Dapeng Mi
2025-01-23 14:07 ` [PATCH 20/20] perf tools/tests: Add vector registers PEBS sampling test Dapeng Mi

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=1338dd77-e9c1-4eac-9d0f-195829acdd2a@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dapeng1.mi@intel.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=kan.liang@linux.intel.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