[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec1dca74ee606fb72a382ee55f91d99b2373b816.camel@intel.com>
Date: Tue, 21 Feb 2023 08:01:44 +0000
From: "Zhang, Rui" <rui.zhang@...el.com>
To: "peterz@...radead.org" <peterz@...radead.org>
CC: "Brown, Len" <len.brown@...el.com>,
"zhang.jia@...ux.alibaba.com" <zhang.jia@...ux.alibaba.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH V2 0/1] x86: cpu topology fix and question on
x86_max_cores
Hi, Peter,
> We could add an assertion in SMP bringup that the APIC-ID from MADT
> matches the state as read from CPUID ? If that matches (it really
> should) then using the MADT table IDs early should work and at least
> give us a litle bit more data.
>
> APIC-ID is of no use vs hybrid though,
Do you have any pointer to the hybrid issue you're referring to here?
In which case we need to know how many type of cores?
thanks,
rui
Powered by blists - more mailing lists