[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bkloosq1.ffs@tglx>
Date: Mon, 20 Feb 2023 23:52:06 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>,
"Zhang, Rui" <rui.zhang@...el.com>
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>,
"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
On Mon, Feb 20 2023 at 20:06, Peter Zijlstra wrote:
> On Mon, Feb 20, 2023 at 02:33:09PM +0000, Zhang, Rui wrote:
> APIC-ID is of no use vs hybrid though, and MADT doesn't include any
> either, so that's all still buggered.
>
> Luckily it looks like MADT is fairly extensible, ideally we add an field
> to entry-type-0 to help with the hybrid mess.
I don't think that's the right way. This should use PPTT because that's
a proper hierarchy model. Extending MADT is just another duct tape
solution.
And it actually does not matter which way we go because none of the
existing systems have any of that.
Thanks,
tglx
Powered by blists - more mailing lists