[PATCH v2 2/2] perf: arm_pmuv3: Don't use PMCCNTR_EL0 on SMT cores

Will Deacon will at kernel.org
Fri Sep 19 04:18:45 PDT 2025


On Fri, Sep 19, 2025 at 10:37:45AM +0100, Sudeep Holla wrote:
> On Thu, Sep 18, 2025 at 02:32:20PM +0100, Will Deacon wrote:
> > On Wed, Aug 20, 2025 at 04:45:34PM +0800, Yicong Yang wrote:
> > > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
> > > index d72d6e5aa200..daa1af2e8204 100644
> > > --- a/include/linux/arch_topology.h
> > > +++ b/include/linux/arch_topology.h
> > > @@ -89,6 +89,17 @@ void remove_cpu_topology(unsigned int cpuid);
> > >  void reset_cpu_topology(void);
> > >  int parse_acpi_topology(void);
> > >  void freq_inv_set_max_ratio(int cpu, u64 max_rate);
> > > +
> > > +/*
> > > + * Architectures like ARM64 don't have reliable architectural way to get SMT
> > > + * information and depend on the firmware (ACPI/OF) report. Non-SMT core won't
> > > + * initialize thread_id so we can use this to detect the SMT implementation.
> > > + */
> > > +static inline bool topology_core_has_smt(int cpu)
> > > +{
> > > +	return cpu_topology[cpu].thread_id != -1;
> > > +}
> > 
> > Sudeep -- is this ok?
> > 
> 
> Yes, this looks correct as the topology_sibling_cpumask(aka thread_sibling
> mask) changes with hotplug events and may not be desirable. Not sure if we
> can do any better with name in case we need to check for active/online thread
> sibling in the future(I assuming it is for sure not needed here).

Great, thanks for confirming. We're just using this to figure out whether
the hardware implements SMT so I don't think we care about the thread status
at all.

Will



More information about the linux-arm-kernel mailing list