[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e332573f03ec441d9b357c7cfb6852ba@AcuMS.aculab.com>
Date: Fri, 3 Dec 2021 09:20:01 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Dave Hansen' <dave.hansen@...el.com>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
"x86@...nel.org" <x86@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"hpa@...or.com" <hpa@...or.com>,
"chang.seok.bae@...el.com" <chang.seok.bae@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 00/10] x86: Allocate AVX512 xstate ondemand
From: Dave Hansen
> Sent: 03 December 2021 00:59
>
> On 12/2/21 4:45 PM, Jiaxun Yang wrote:
> > 在2021年12月3日十二月 上午12:40,Dave Hansen写道:
> >> On 12/2/21 4:36 PM, Jiaxun Yang wrote:
> >>> Also we are going to have heterogeneous processors that
> >>> only some cores support AVX512, it can be helpful when
> >>> dealing with such processors.
> >> Really? Which x86 vendor is doing that?
> > Clear lower two bits of MSR 0xAF on Alder Lake give me some suprise :-)
>
> I honestly don't know what you're talking about. Does poking that MSR
> allowing AVX512 instructions to be executed on cores where it was
> otherwise disabled? That's entertaining, but it's far from "supported"
> or even support*able* in Linux.
I can also imagine chips being tested and tested and marked
differently depending on what works.
So a part with faulty AVX512 will be marked as BIG+little with AVX512 disabled.
A part with working AVX512 will have the 'little' cpu disabled.
A lot of this is actually setup by the BIOS code.
Cheating will cause grief.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists