[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251031053832.99453-1-fushuai.wang@linux.dev>
Date: Fri, 31 Oct 2025 13:38:32 +0800
From: Fushuai Wang <fushuai.wang@...ux.dev>
To: bp@...en8.de
Cc: dave.hansen@...ux.intel.com,
davydov-max@...dex-team.ru,
gpiccoli@...lia.com,
hpa@...or.com,
jani.nikula@...el.com,
joel.granados@...nel.org,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
martin.petersen@...cle.com,
mingo@...hat.com,
peterz@...radead.org,
tglx@...utronix.de,
wangfushuai@...du.com,
x86@...nel.org,
xin@...or.com
Subject: Re: [PATCH RESEND] x86/split_lock: Make split lock mitigation sleep duration configurable
>> 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.
Powered by blists - more mailing lists