Re: [PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable

[Fushuai Wang <fushuai.wang@linux.dev>]

>> Commit 727209376f49 ("x86/split_lock: Add sysctl to control the misery
>> mode") introduce a sysctl 'sysctl_sld_mitigate' to control the misery
>> mode for split lock detection (0 to disable, 1 to enable). However,
>> when enabled, the sleep duration for split lockers was fixed at 10 ms.
>> 
>> This patch extands 'sysctl_sld_mitigate' to allow configuring the sleep
>> duration in milliseconds. Now, when 'sysctl_sld_mitigate' is set to
>> N (N > 0), split lockers will sleep for N milliseconds.
>
> I'm reading this and the only question that pops up in my mind is "why".
> 
> Why does the upstream kernel need this?
-------
Resend. It was not delivered successfully again. :(
-------

Hi Boris,

I think there are two main reasons for making the split lock mitigation
sleep duration configurable:

1.Workload Flexibility: Different workloads have varying sensitivity to
  latency. Some environments may want a longer penalty to strongly discourage
  split locks, while others may prefer a shorter delay to minimize impact on
  overall system responsiveness.For example, in cloud environments, we are
  often more sensitive to split locks because it is important to prevent a
  single virtual machine from impacting the performance of the entire physical
  host, so a stricter (longer) penalty may be preferred. In other scenarios,
  such a strict penalty may not be necessary, and a shorter delay might be
  sufficient to balance performance and stability. Making the sleep duration
  configurable allows administrators to adjust the mitigation strategy based
  on the specific requirements and tolerance levels of different environments.

2.Testing and Tuning: Allowing the sleep duration to be configured makes
  it easier for system administrators and developers to test the effects of
  different mitigation levels and to tune the system according to their
  specific requirements.

Regards,
Wang.