[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMei5uMRwOJo2r6Z@feng-clx>
Date: Mon, 31 Jul 2023 20:02:46 +0800
From: Feng Tang <feng.tang@...el.com>
To: kernel test robot <oliver.sang@...el.com>,
Thomas Gleixner <tglx@...utronix.de>
CC: <x86@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
<oe-lkp@...ts.linux.dev>, <lkp@...el.com>,
<linux-kernel@...r.kernel.org>, <ying.huang@...el.com>,
<fengwei.yin@...el.com>
Subject: Re: [linus:master] [x86/fpu] b81fac906a:
stress-ng.af-alg.ops_per_sec -34.6% regression
On Wed, Jul 19, 2023 at 10:07:52PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed a -34.6% regression of stress-ng.af-alg.ops_per_sec on:
>
>
> commit: b81fac906a8f9e682e513ddd95697ec7a20878d4 ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> still regression on:
> fix commit: fe3e0a13e597c1c8617814bf9b42ab732db5c26e
> linus/master: ccff6d117d8dc8d8d86e8695a75e5f8b01e573bf
>
> testcase: stress-ng
> test machine: 64 threads 2 sockets Intel(R) Xeon(R) Gold 6346 CPU @ 3.10GHz (Ice Lake) with 256G memory
> parameters:
>
> nr_threads: 10%
> disk: 1HDD
> testtime: 60s
> fs: ext4
> class: os
> test: af-alg
> cpufreq_governor: performance
>
>
> besides, we noticed there are below information in dmesg (attached kmsg.xz),
> which we didn't see in dmesg for parent:
>
> kern :info : [ 65.660392] AVX or AES-NI instructions are not detected.
> user :notice: [ 65.661743] stress-ng: info: [4738] af-alg: 9 cryptographic algorithms are internal and may be unused
>
> kern :info : [ 65.720205] AVX or AES-NI instructions are not detected.
> kern :info : [ 65.820334] AVX2 instructions are not detected.
> kern :info : [ 66.130644] AVX or AES-NI instructions are not detected.
> kern :info : [ 66.167749] AVX or AES-NI instructions are not detected.
> kern :info : [ 66.213178] AVX2 instructions are not detected.
> kern :info : [ 66.318235] AVX or AES-NI instructions are not detected.
> kern :info : [ 66.360766] AVX or AES-NI instructions are not detected.
> kern :info : [ 66.437318] AVX2 instructions are not detected.
> kern :info : [ 66.683666] AVX or AES-NI instructions are not detected.
> user :notice: [ 66.713976] BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
>
> kern :info : [ 66.738790] AVX or AES-NI instructions are not detected.
> kern :info : [ 66.822332] AVX2 instructions are not detected.
> kern :info : [ 67.083360] AVX or AES-NI instructions are not detected.
> kern :info : [ 67.122804] AVX or AES-NI instructions are not detected.
I think the regression is related with the commit, that commit
b81fac906a8f changes the FPU init order, and cause the 'X86_FEATURE_OSXSAVE'
missed the cpu capability setup, thus all later check of
boot_cpu_has(X86_FEATURE_OSXSAVE) will return false.
arch_cpu_finalize_init
identify_boot_cpu
identify_cpu
generic_identify
get_cpu_cap --> setup cpu capability
...
fpu__init_cpu
fpu__init_cpu_xstate
cr4_set_bits(X86_CR4_OSXSAVE);
Many security moduels in arch/x86 have dependency on X86_FEATURE_OSXSAVE,
and will fail to load later. While this 'af-alg' case involves secuirty
operation and tries to load those modules but fail, which cause the
regression.
Setting the 'OSXSVAE' feature bit after OSXSAVE enabling can restore
the regression, like the below RFC patch. pls help to review, thanks!
- Feng
---
>From 62d05a24cae9198b0ed45a8857edbe4c9c4184f9 Mon Sep 17 00:00:00 2001
From: Feng Tang <feng.tang@...el.com>
Date: Mon, 31 Jul 2023 16:45:34 +0800
Subject: [PATCH RFC] x86/fpu: set X86_FEATURE_OSXSAVE feature after enabling
OSXSAVE in CR4
Commit b81fac906a8f ("x86/fpu: Move FPU initialization into
arch_cpu_finalize_init()" optimized the FPU init order, and moves the
CR4_OSXSAVE enabling into a later flace.
arch_cpu_finalize_init
identify_boot_cpu
identify_cpu
generic_identify
get_cpu_cap --> setup cpu capability
...
fpu__init_cpu
fpu__init_cpu_xstate
cr4_set_bits(X86_CR4_OSXSAVE);
This makes 'X86_FEATURE_OSXSAVE' missed in cpu capability setup. Many
security module like 'camellia_aesni_avx_x86_64' depends on this feature
and will fail to load after the commit. 0Day caught a 34% regression
in stress-ng's 'af-alg' test case [1].
So set X86_FEATURE_OSXSAVE feature after OSXSAVE enabling to fix it.
[1]. https://lore.kernel.org/lkml/202307192135.203ac24e-oliver.sang@intel.com/
Fixes: b81fac906a8f ("x86/fpu: Move FPU initialization into arch_cpu_finalize_init()")
Reported-by: kernel test robot <oliver.sang@...el.com>
Signed-off-by: Feng Tang <feng.tang@...el.com>
---
arch/x86/kernel/fpu/xstate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 0bab497c9436..8ebea0d522d2 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -173,6 +173,9 @@ void fpu__init_cpu_xstate(void)
cr4_set_bits(X86_CR4_OSXSAVE);
+ if (!boot_cpu_has(X86_FEATURE_OSXSAVE))
+ setup_force_cpu_cap(X86_FEATURE_OSXSAVE);
+
/*
* Must happen after CR4 setup and before xsetbv() to allow KVM
* lazy passthrough. Write independent of the dynamic state static
--
2.27.0
Powered by blists - more mailing lists