Messages in this thread | | | Subject | Re: [PATCH v1 1/2] x86/tsc: use logical_package as a better estimation of socket numbers | From | Zhang Rui <> | Date | Sun, 23 Oct 2022 00:12:38 +0800 |
| |
On Fri, 2022-10-21 at 09:21 -0700, Dave Hansen wrote: > On 10/21/22 08:00, Zhang Rui wrote: > > I checked the history of '__max_logical_packages', and realized > > that > > > > 1. for topology_max_packages()/'__max_logical_packages', the > > divisor > > 'ncpus' uses cpu_data(0).booted_cores, which is based on the > > *online* CPUs. So when using kernel cmdlines like > > maxcpus=/nr_cpus=, > > '__max_logical_packages' can get over-estimated. > > > > > > 2. for 'logical_packages', it equals the number of different > > physical > > Package IDs for all *online* CPUs. So with kernel cmdlines like > > nr_cpus=/maxcpus=, it can gets under-estimated. > > > > BTW, I also checked CPUID.B/1F, which can tell a fixed number of > > CPUs > > within a package. But we don't have a fixed number of total CPUs > > from > > hardware. > > On my Dell laptop, BIOS allows me to disable/enable one or several > > cores. When this happens, the 'total_cpus' changes, but CPUID.B/1F > > does > > not change. So I don't think CPUID.B/1F can be used to optimize the > > '__ > > max_logical_packages' calculation. > > > > I'm not sure if we have a perfect solution here. > > Are the implementations fixable?
currently, I don't have any idea.
> Or, at least tolerable? > > For instance, I can live with the implementation being a bit goofy > when > kernel commandlines are in play. We can pr_info() about those cases.
My understanding is that the cpus in the last package may still have small cpu id value. This means that the 'logical_packages' is hard to break unless we boot with very small CPU count and happened to disable all cpus in one/more packages. Feng is experiencing with this and may have some update later.
If this is the case, is this a valid case that we need to take care of?
thanks, rui
| |