All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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>,
	Kan Liang <kan.liang@linux.intel.com>,
	linux-kernel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
	Zhenyu Wang <zhenyuw@linux.intel.com>,
	Yongwei Ma <yongwei.ma@intel.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [PATCH 3/4] perf/x86/intel: Support hybrid PMU with multiple atom uarchs
Date: Mon, 12 Aug 2024 11:18:34 +0800	[thread overview]
Message-ID: <08671266-6daa-4bab-bea8-2a9fa6f0fdc3@linux.intel.com> (raw)
In-Reply-To: <20240810215539.GG11646@noisy.programming.kicks-ass.net>


On 8/11/2024 5:55 AM, Peter Zijlstra wrote:
> On Thu, Aug 08, 2024 at 02:02:09PM +0000, Dapeng Mi wrote:
>>  arch/x86/events/intel/core.c | 24 +++++++++++++++++-------
>>  arch/x86/events/perf_event.h | 18 +++++++++++++++++-
>>  2 files changed, 34 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 0c9c2706d4ec..b6429bc009c0 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -6218,6 +6227,7 @@ static inline int intel_pmu_v6_addr_offset(int index, bool eventsel)
>>  static const struct { enum hybrid_pmu_type id; char *name; } intel_hybrid_pmu_type_map[] __initconst = {
>>  	{ hybrid_small, "cpu_atom" },
>>  	{ hybrid_big, "cpu_core" },
>> +	{ hybrid_small2, "cpu_atom2" },
> This is awfully uninspired and quite terrible. How is one supposed to
> know which is which? A possibly better naming might be: hybrid_tiny,
> "cpu_lowpower" or whatever.

We have lots of discussion internally about the naming, but unfortunately
we can't come to a conclusion. The reason that we select "cpu_atom2" is
that it's generic enough and won't expose too much model specific
information, we can reuse it if there are similar platforms in the future.
But of course I admit the name is indeed uninspired and easy to cause
confusion.

The other names which I ever discussed are "cpu_lp_soc", "cpu_soc" and
"cpu_atom_soc", but this name would expose some model specific architecture
information more or less, not sure which one is better. How is your opinion
on this?


>
>>  };
>>  
>>  static __always_inline int intel_pmu_init_hybrid(enum hybrid_pmu_type pmus)
>> @@ -6250,7 +6260,7 @@ static __always_inline int intel_pmu_init_hybrid(enum hybrid_pmu_type pmus)
>>  							0, x86_pmu_num_counters(&pmu->pmu), 0, 0);
>>  
>>  		pmu->intel_cap.capabilities = x86_pmu.intel_cap.capabilities;
>> -		if (pmu->pmu_type & hybrid_small) {
>> +		if (pmu->pmu_type & hybrid_small_all) {
>>  			pmu->intel_cap.perf_metrics = 0;
>>  			pmu->intel_cap.pebs_output_pt_available = 1;
>>  			pmu->mid_ack = true;
>> diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
>> index 5d1677844e04..f7b55c909eff 100644
>> --- a/arch/x86/events/perf_event.h
>> +++ b/arch/x86/events/perf_event.h
>> @@ -668,6 +668,13 @@ enum {
>>  #define PERF_PEBS_DATA_SOURCE_GRT_MAX	0x10
>>  #define PERF_PEBS_DATA_SOURCE_GRT_MASK	(PERF_PEBS_DATA_SOURCE_GRT_MAX - 1)
>>  
>> +
>> +/*
>> + * CPUID.1AH.EAX[31:0] uniquely identifies the microarchitecture
>> + * of the core. Bits 31-24 indicates its core type (Core or Atom)
>> + * and Bits [23:0] indicates the native model ID of the core.
>> + * Core type and native model ID are defined in below enumerations.
>> + */
>>  enum hybrid_cpu_type {
>>  	HYBRID_INTEL_NONE,
>>  	HYBRID_INTEL_ATOM	= 0x20,
>> @@ -676,12 +683,21 @@ enum hybrid_cpu_type {
>>  
>>  #define X86_HYBRID_PMU_ATOM_IDX		0
>>  #define X86_HYBRID_PMU_CORE_IDX		1
>> +#define X86_HYBRID_PMU_ATOM2_IDX	2
>>  enum hybrid_pmu_type {
>>  	not_hybrid,
>>  	hybrid_small		= BIT(X86_HYBRID_PMU_ATOM_IDX),
>>  	hybrid_big		= BIT(X86_HYBRID_PMU_CORE_IDX),
>> +	hybrid_small2		= BIT(X86_HYBRID_PMU_ATOM2_IDX),
>> +	/* The belows are only used for matching */
>> +	hybrid_big_small	= hybrid_big | hybrid_small,
>> +	hybrid_small_all	= hybrid_small | hybrid_small2,
>> +	hybrid_big_small_arl_h	= hybrid_big | hybrid_small_all,
> Same complaint, how about:
>
> +	hybrid_tiny		= BIT(X86_HYBRID_PMU_TINY_IDX),
> 	hybrid_big_small	= hybrid_big | hybrid_small,
> +	hybrid_small_tiny	= hybrid_small | hybrid_tiny,
> +	hybrid_big_small_tiny	= hybrid_big_small | hybrid_tiny,

Sure. I would adjust the macro name base on the above discussed final name.
Thanks.


>
>
>> +};
>>  
>> -	hybrid_big_small	= hybrid_big | hybrid_small, /* only used for matching */
>> +enum atom_native_id {
>> +	cmt_native_id           = 0x2,  /* Crestmont */
>> +	skt_native_id           = 0x3,  /* Skymont */
>>  };
>>  
>>  struct x86_hybrid_pmu {
>> -- 
>> 2.40.1
>>

  reply	other threads:[~2024-08-12  3:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-08 14:02 [PATCH 0/4] Enable PMU for ArrowLake-H Dapeng Mi
2024-08-08 14:02 ` [PATCH 1/4] perf/x86: Refine hybrid_pmu_type defination Dapeng Mi
2024-08-10 21:35   ` Peter Zijlstra
2024-08-12  2:44     ` Mi, Dapeng
2024-08-08 14:02 ` [PATCH 2/4] x86/cpu/intel: Define helper to get CPU core native ID Dapeng Mi
2024-08-08 14:02 ` [PATCH 3/4] perf/x86/intel: Support hybrid PMU with multiple atom uarchs Dapeng Mi
2024-08-10 21:55   ` Peter Zijlstra
2024-08-12  3:18     ` Mi, Dapeng [this message]
2024-08-12  3:27       ` Zhenyu Wang
2024-08-16  3:54         ` Mi, Dapeng
2024-08-08 14:02 ` [PATCH 4/4] perf/x86/intel: Add PMU support for ArrowLake-H Dapeng Mi
2024-08-08 16:07 ` [PATCH 0/4] Enable PMU " Liang, Kan

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=08671266-6daa-4bab-bea8-2a9fa6f0fdc3@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=irogers@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=yongwei.ma@intel.com \
    --cc=zhenyuw@linux.intel.com \
    /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.