[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YjR5Pl2uAUPbDZzT@otcwcpicx3.sc.intel.com>
Date: Fri, 18 Mar 2022 05:21:18 -0700
From: Fenghua Yu <fenghua.yu@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: David Laight <David.Laight@...LAB.COM>,
'Thomas Gleixner' <tglx@...utronix.de>,
Pavel Machek <pavel@...x.de>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: Re: [PATCH v2 1/2] x86/split_lock: Make life miserable for split
lockers
On Thu, Mar 17, 2022 at 03:40:16PM -0700, Luck, Tony wrote:
> > They are actually more likely to happen in the kernel
> > when code casts int[] to long[] and then uses the 'BIT' functions to
> > set/clear bits - which do locked operations.
> > Quite often then don't need the locks anyway.
> > And that cast is surprisingly common and completely broken on BE.
>
> Default split lock mode is "kernel dies". We had to fix up a dozen or
> so places (mostly involving set_bit/clr_bit as you describe). But
> all Ice Lake. Tiger Lake and Alder Lake systems are running in
> that mode ... and we haven't heard of widespread death (or disabling
> the boot option).
Split lock is designed to report this kind of "hidden" performance issues.
After initial fix up wave, it has been sparse to find any legacy split lock
issue in the kernel.
If a new split lock issue is introduced, the developer hopefully will
capture and fix it before upstream. So others won't see it any more.
Thanks.
-Fenghua
Powered by blists - more mailing lists