Re: [PATCH 09/15] x86/split_lock: Explicitly enable or disable #AC for split locked accesses

[Dave Hansen]

On 05/15/2018 10:29 AM, Fenghua Yu wrote:
> On Tue, May 15, 2018 at 09:15:16AM -0700, Dave Hansen wrote:
>> On 05/14/2018 11:52 AM, Fenghua Yu wrote:
>>> By default, we don't set or clear the bit 29 in TEST_CTL MSR 0x33 and
>>> the bit is inherited from BIOS/hardware setting.
>>>
>>> The kernel parameter "split_lock_ac=on/off" explicitly sets or clears
>>> the bit during boot time.
>>
>> The more I think about this...  Why do we need this at boot anyway?
>> Surely boot-time kernel code can't cause performance issues in the same
>> way that untrusted repeated userspace can.  Why don't we just let
>> userspace turn this on?
> 
> Turning split lock earlier can captuer split lock performance issue
> in the boot path. Actually we did find two split lock issues during
> boot time by turning on the feature earlier (see patch 4 and 5).

Yeah, but you're going to have a pretty hard time arguing that these are
even close to the same class of issues that occur when all the CPUs are
up and userspace is pounding the system with split locks.

It also seems like the kind of thing that deserves to be a debugging
option, or Kconfig thing rather than a kernel command-line option that
has to live forever.