[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZiYbPZ1biNCEndKZ@yujie-X299>
Date: Mon, 22 Apr 2024 16:09:33 +0800
From: Yujie Liu <yujie.liu@...el.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>, Linus Torvalds
<torvalds@...ux-foundation.org>, Daniel Sneddon
<daniel.sneddon@...ux.intel.com>, Pawan Gupta
<pawan.kumar.gupta@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>,
Alexandre Chartre <alexandre.chartre@...cle.com>, Konrad Rzeszutek Wilk
<konrad.wilk@...cle.com>, Peter Zijlstra <peterz@...radead.org>, "Greg
Kroah-Hartman" <gregkh@...uxfoundation.org>, Sean Christopherson
<seanjc@...gle.com>, Andrew Cooper <andrew.cooper3@...rix.com>, Dave Hansen
<dave.hansen@...ux.intel.com>, Nikolay Borisov <nik.borisov@...e.com>, "KP
Singh" <kpsingh@...nel.org>, Waiman Long <longman@...hat.com>, "Borislav
Petkov" <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v4 1/5] x86/bugs: Only harden syscalls when needed
On Fri, Apr 19, 2024 at 02:09:47PM -0700, Josh Poimboeuf wrote:
> Syscall hardening (converting the syscall indirect branch to a series of
> direct branches) has shown some performance regressions:
>
> - Red Hat internal testing showed up to 12% slowdowns in database
> benchmark testing on Sapphire Rapids when the DB was stressed with 80+
> users to cause contention.
>
> - The kernel test robot's will-it-scale benchmarks showed significant
> regressions on Skylake with IBRS:
> https://lkml.kernel.org/lkml/202404191333.178a0eed-yujie.liu@intel.com
To clarify, we reported a +1.4% improvement (not regression) of
will-it-scale futex4 benchmark on Skylake. Meanwhile we did observe some
regressions by running other benchmarks on Ice Lake, such as:
stress-ng.null.ops_per_sec -4.0% regression on Intel Xeon Gold 6346 (Ice Lake)
unixbench.fsbuffer.throughput -1.4% regression on Intel Xeon Gold 6346 (Ice Lake)
>
> To fix those slowdowns, only use the syscall direct branches when
> indirect branches are considered to be "not OK": meaning Spectre v2+BHI
> isn't mitigated by HW and the user hasn't disabled mitigations.
Powered by blists - more mailing lists