[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h9h0pody.fsf@tassilo.jf.intel.com>
Date: Mon, 22 Feb 2016 10:54:01 -0800
From: Andi Kleen <andi@...stfloor.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
Borislav Petkov <bp@...en8.de>,
Stephane Eranian <eranian@...gle.com>,
Harish Chegondi <harish.chegondi@...el.com>,
Kan Liang <kan.liang@...el.com>,
Andi Kleen <andi.kleen@...el.com>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [patch V2 11/28] x86/topology: Create logical package id
Thomas Gleixner <tglx@...utronix.de> writes:
> +
> + if (c->cpuid_level >= 0x00000001) {
> + u32 eax, ebx, ecx, edx;
> +
> + cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
Use cpuid_edx()
> + /*
> + * If HTT (EDX[28]) is set EBX[16:23] contain the number of
> + * apicids which are reserved per package. Store the resulting
> + * shift value for the package management code.
> + */
> + if (edx & (1U << 28))
> + c->x86_coreid_bits = get_count_order((ebx >> 16) & 0xff);
> + }
> +++ b/arch/x86/kernel/cpu/proc.c
> @@ -12,6 +12,7 @@ static void show_cpuinfo_core(struct seq
> {
> #ifdef CONFIG_SMP
> seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
> + seq_printf(m, "logical id\t: %d\n", c->logical_proc_id);
I'm not sure it makes sense to export this. What good would it be for
the user?
If it was it would need to be documented somewhere. But I would
just drop it and keep it kernel internal.
FWIW every time something is added to this file it usually breaks
some (dumb) programs.
> + /*
> + * Today neither Intel nor AMD support heterogenous systems. That
> + * might change in the future....
> + */
> + ncpus = boot_cpu_data.x86_max_cores * smp_num_siblings;
> + __max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
FWIW Hypervisors can do nearly everything today.
I assume your code handles it.
Let's hope that the Hypervisors always set up the correct CPUID now
for their sibling configuration. If they don't with this change
some CPUs would be suddenly lost.
Would it be worth to have a kernel option where the maximum can be overriden
in case this happens?
-Andi
--
ak@...ux.intel.com -- Speaking for myself only
Powered by blists - more mailing lists