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

[Fenghua Yu]

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).

I guess how to improve boot time is still a concern for client and VM.
If split lock issue can be identified and fixed in boot time, it just
helps and dosn't hurt anything.

Turning on the feature during boot time makes user easier to identify
any split lock issue not just during boot time and also run time.

Having said that, there is a sysfs interface in patch #10 that allows
user to turn on/off the feature during boot time.

Does that sound better?

Thanks.

-Fenghua