[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o8fda2ye.fsf@nanos.tec.linutronix.de>
Date: Sat, 20 Mar 2021 23:13:29 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Chang S. Bae" <chang.seok.bae@...el.com>, bp@...e.de,
luto@...nel.org, mingo@...nel.org, x86@...nel.org
Cc: len.brown@...el.com, dave.hansen@...el.com, jing2.liu@...el.com,
ravi.v.shankar@...el.com, linux-kernel@...r.kernel.org,
chang.seok.bae@...el.com
Subject: Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state
On Sun, Feb 21 2021 at 10:56, Chang S. Bae wrote:
> +
> +/* Update MSR IA32_XFD with xfirstuse_not_detected() if needed. */
> +static inline void xdisable_switch(struct fpu *prev, struct fpu *next)
> +{
> + if (!static_cpu_has(X86_FEATURE_XFD) || !xfirstuse_enabled())
> + return;
> +
> + if (unlikely(prev->state_mask != next->state_mask))
> + xdisable_setbits(xfirstuse_not_detected(next));
> +}
So this is invoked on context switch. Toggling bit 18 of MSR_IA32_XFD
when it does not match. The spec document says:
"System software may disable use of Intel AMX by clearing XCR0[18:17], by
clearing CR4.OSXSAVE, or by setting IA32_XFD[18]. It is recommended that
system software initialize AMX state (e.g., by executing TILERELEASE)
before doing so. This is because maintaining AMX state in a
non-initialized state may have negative power and performance
implications."
I'm not seeing anything related to this. Is this a recommendation
which can be ignored or is that going to be duct taped into the code
base once the first user complains about slowdowns of their non AMX
workloads on that machine?
Thanks,
tglx
Powered by blists - more mailing lists