Re: [PATCH v2] arch_topology: Introduce nr_possible_packages
From: Feng Tang
Date: Thu Jul 23 2026 - 04:37:13 EST
On Wed, Jul 22, 2026 at 09:41:54AM +0100, Sudeep Holla wrote:
> On Tue, Jul 14, 2026 at 01:43:17PM +0800, Feng Tang wrote:
> > For multi-sockets platforms kernel or driver code may need the number
> > of packages to chose different code directions. Some architecture
> > already provides such kind of interface like x86, which is being used
> > in its architecture code and drivers.
> >
> > Add similar interface 'nr_possible_packages' for platforms which can
> > get package topology information by parsing ACPI tables in boot phase,
> > which was verified to show the correct number of packages on some
> > 1-socket and 2-sockets production arm64 servers from different vendors.
> >
> > It has been used locally by some arm64 PMU driver, and cross-socket
> > timer-consistency check code, which are to be posted.
[...]
> >
> > +unsigned int nr_possible_packages __ro_after_init;
> > +EXPORT_SYMBOL(nr_possible_packages);
> > +
> > +static int package_ids[1 << CONFIG_NODES_SHIFT] __initdata;
Thanks for the suggestion!
> Since all you need is just the total number of packages, this whole
> array may not be required.
Yes. I also made it '__initdata' to be freed later.
> static unsigned int topology_count_packages(const struct cpumask *cpus)
> {
> unsigned int cpu, prev, count = 0;
> int package_id;
>
> for_each_cpu(cpu, cpus) {
> package_id = cpu_topology[cpu].package_id;
> if (package_id < 0)
> continue;
>
> for_each_cpu(prev, cpus) {
> if (prev == cpu) {
> count++;
> break;
> }
>
> if (cpu_topology[prev].package_id == package_id)
> break;
> }
> }
>
> return count;
> }
>
> Something like this would suffice, no ?
This is a good point, that I don't have to call count_packages()
and use global array for each cpu, but do this package counting
all together after CPUs have been parsed and before exitting
parse_acpi_topology().
One thing is, from PPTT table, the package ID is u32, so we
can't say 0xffffffff (-1) is illegal (though I think it's insane
to really use it :)). Anyway, I'll test more in this direction.
Thanks,
Feng