On Sun, Dec 18, 2022 at 08:44:00PM -0300, Guilherme G. Piccoli wrote:
commit 727209376f4998bc84db1d5d8af15afea846a92b upstream.
Commit b041b525dab9 ("x86/split_lock: Make life miserable for split lockers") changed the way the split lock detector works when in "warn" mode; basically, it not only shows the warn message, but also intentionally introduces a slowdown through sleeping plus serialization mechanism on such task. Based on discussions in [0], seems the warning alone wasn't enough motivation for userspace developers to fix their applications.
This slowdown is enough to totally break some proprietary (aka. unfixable) userspace[1].
Happens that originally the proposal in [0] was to add a new mode which would warns + slowdown the "split locking" task, keeping the old warn mode untouched. In the end, that idea was discarded and the regular/default "warn" mode now slows down the applications. This is quite aggressive with regards proprietary/legacy programs that basically are unable to properly run in kernel with this change. While it is understandable that a malicious application could DoS by split locking, it seems unacceptable to regress old/proprietary userspace programs through a default configuration that previously worked. An example of such breakage was reported in [1].
Add a sysctl to allow controlling the "misery mode" behavior, as per Thomas suggestion on [2]. This way, users running legacy and/or proprietary software are allowed to still execute them with a decent performance while still observing the warning messages on kernel log.
[0] https://lore.kernel.org/lkml/20220217012721.9694-1-tony.luck@intel.com/ [1] https://github.com/doitsujin/dxvk/issues/2938 [2] https://lore.kernel.org/lkml/87pmf4bter.ffs@tglx/
[ dhansen: minor changelog tweaks, including clarifying the actual problem ]
Fixes: b041b525dab9 ("x86/split_lock: Make life miserable for split lockers") Suggested-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Guilherme G. Piccoli gpiccoli@igalia.com Signed-off-by: Dave Hansen dave.hansen@linux.intel.com Reviewed-by: Tony Luck tony.luck@intel.com Tested-by: Andre Almeida andrealmeid@igalia.com Link: https://lore.kernel.org/all/20221024200254.635256-1-gpiccoli%40igalia.com
Hi folks, I've build tested this on both 6.0.13 and 6.1, worked fine. The split lock detector code changed almost nothing since 6.0, so that makes sense...
I think this is important to have in stable, some gaming community members seems excited with that, it'll help with general proprietary software (that is basically unfixable), making them run smoothly on 6.0.y and 6.1.y.
What specific programs have this problem and what are the exact results of it?
Also, this is really a new feature and not really a "fix", but one could argue a lot that this is a "resolve a performance problem" if you want to and have the numbers to back it up {hint}
thanks,
greg k-h