The search for the correct amount of split-lock misery [Linux]
-
This post did not contain any content.
-
Others disagreed, though. Joshua Ashton argued that the problem is more widespread: ““It’s not just about God of War specifically. There are many old titles that will never, ever, get updated to fix this problem. These titles worked perfectly fine and were performant before.””
The problem is that this sort of thing works well with open-source software, where the stuff can always be fixed, but isn’t going to do much of anything with closed-source software like old Windows games.
It might be possible to introduce some sort of fancy code-mangling stuff to WINE that can in-memory modify binaries doing this. Like, I’m kind of guessing that God of War most likely isn’t trying to synchronize access with anything other than its own threads, so it doesn’t actually require atomicity as regards anything else on the system. Maybe it’s possible to patch the code in question to jump out to some WINE code that acquires a mutex and then does the memory modification/access. That’ll still probably impact performance, but not to the tune of 10 ms of delay per access, and it’ll keep the occasional poorly-written WINE game from killing system performance.
-
Others disagreed, though. Joshua Ashton argued that the problem is more widespread: ““It’s not just about God of War specifically. There are many old titles that will never, ever, get updated to fix this problem. These titles worked perfectly fine and were performant before.””
The problem is that this sort of thing works well with open-source software, where the stuff can always be fixed, but isn’t going to do much of anything with closed-source software like old Windows games.
It might be possible to introduce some sort of fancy code-mangling stuff to WINE that can in-memory modify binaries doing this. Like, I’m kind of guessing that God of War most likely isn’t trying to synchronize access with anything other than its own threads, so it doesn’t actually require atomicity as regards anything else on the system. Maybe it’s possible to patch the code in question to jump out to some WINE code that acquires a mutex and then does the memory modification/access. That’ll still probably impact performance, but not to the tune of 10 ms of delay per access, and it’ll keep the occasional poorly-written WINE game from killing system performance.
The new kernel.split_lock_mitigate knob, if set to zero, will disable the penalization of processes using split locking (while retaining the warning sent to the system log)
Sounds to me like it’s fixed. WINE could follow dmesg, and show a popup with recommendations when it detects one of its processes is getting throttled.
-
The new kernel.split_lock_mitigate knob, if set to zero, will disable the penalization of processes using split locking (while retaining the warning sent to the system log)
Sounds to me like it’s fixed. WINE could follow dmesg, and show a popup with recommendations when it detects one of its processes is getting throttled.
It still has the performance impact for the rest of the system if one re-enables it.
-
It still has the performance impact for the rest of the system if one re-enables it.
As long as you can re-disable it after playing the game…
I know, all background processes get impacted during gameplay, but that was the case already. The popup can explain the tradeoff, and who’s to blame (game dev).
