|
|
Subscribe / Log in / New account

The search for the correct amount of split-lock misery

The search for the correct amount of split-lock misery

Posted Oct 19, 2022 19:37 UTC (Wed) by epa (subscriber, #39769)
In reply to: The search for the correct amount of split-lock misery by mss
Parent article: The search for the correct amount of split-lock misery

To which the only answer is ‘suck it and see’. If the game still runs, doesn’t crash or behave strangely, then the looser behaviour is good enough.


to post comments

The search for the correct amount of split-lock misery

Posted Oct 19, 2022 20:15 UTC (Wed) by mb (subscriber, #50428) [Link] (9 responses)

What you gained: Nothing at all. On a gaming system there is no concern of stalled or otherwise DoSed other applications, because there are none.

What you payed: The game crashes or sporadically misbehaves or is slower than before.

In a single application scenario, which a game effectively is, the only task of the kernel is to make that application run as smooth as possible.
If there is a change to the kernel, which reduces game performance with no additional gain whatsoever, then it is a regression.
Clearly, there is no stalling problem of other applications, because it would have been noticed by the game developer before. This is mitigating a problem, that doesn't exist in this scenario.

The search for the correct amount of split-lock misery

Posted Oct 19, 2022 22:14 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (6 responses)

> On a gaming system there is no concern of stalled or otherwise DoSed other applications, because there are none.

Unless you're streaming to Twitch, or your multiplayer game has no built-in chat and you're using a third-party application to communicate with your fellow players, or you hate the in-game music and are running a media player to get a soundtrack you actually like, or ...

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 3:10 UTC (Thu) by mb (subscriber, #50428) [Link] (5 responses)

And neither of these situations is improved or solved by stalling the game (the app that uses split locks).
It always reduces the user experience. It doesn't improve anything.

I would go as far to argue that throttling an application due to split locks on a single user system is always wrong.
The only case where we gain something from throttling the app is on a multiuser system where one user is maliciously attacking the system as a whole. (This might be an unpriviledged remote user who might not even need a system account).

The search for the correct amount of split-lock misery

Posted Oct 24, 2022 6:20 UTC (Mon) by marcH (subscriber, #57642) [Link] (3 responses)

It improves the future for maintained and future apps. For everything except orphaned apps.

The search for the correct amount of split-lock misery

Posted Oct 28, 2022 11:52 UTC (Fri) by Vipketsh (guest, #134480) [Link] (2 responses)

If you are only ever looking to make the future good, the present will *always* suck.

Is there any known exploit using this scenario to guard against ? I mean, users shouldn't go off and install random "break my machine" programs or if they do DoS-ing an individual's machine isn't exactly beneficial, nor is it the worst that an evil application can do.

I see this change and behaviour as more inline with the seemingly recent trend that the linux kernel is to do well out-of-the-box for cloud-based deployments, and only as a second concession allow individuals to tweak things so their single-user laptops and systems may work reasonably. A little sad and quite backwards since cloud operators have lots of talent on hand to tweak and analyse their systems (and they do anyway) with which individuals can't hope to compete.

The search for the correct amount of split-lock misery

Posted Oct 28, 2022 22:18 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> If you are only ever looking to make the future good, the present will *always* suck.

Actually, by stalling abusive applications this improves the present of other applications too. Single app gaming really does not feel like a top Linux use case today. Unless you're counting ChromeOS, Android and Steam deck but then you're not administering your own system and you can count on its admins to optimize all this for you.

> Is there any known exploit using this scenario to guard against ?

This is not just about intentional abuse but also about performance under unintentional abuse too.

> recent trend that the linux kernel is to do well out-of-the-box for cloud-based deployments, and only as a second concession allow individuals

As already explained elsewhere this is not just about multi-user but about multi process in general.

The search for the correct amount of split-lock misery

Posted Oct 29, 2022 2:30 UTC (Sat) by Vipketsh (guest, #134480) [Link]

> by stalling abusive applications this improves the present of other applications too

In theory I understand, but do you or anyone else have any numbers to the magnitude of this slowdown on, say, a typical 4/8 core laptop ? Theoretical problems should always be trumped by practical breakage, until proven otherwise.

This is like arguing that some application causing heavy contention on a kernel lock is a DoS attack or, if not that, the application is slowing down the system and thus the kernel should prevent it from running. Clearly this is madness. How are split locks any different ?

> also about performance under unintentional abuse too.

The malicious case is all that matters. For everything else, one of two possible outcomes is possible: (i) the performance issue is fixed and so is not a problem or (ii) the performance issue is not fixed in which case the choices are "slow(er) system" and "program does not work". A slower system is *always* preferred to a non working one and that is doubly true for machines of individuals.

Also let's not forget that this case is only relevant to x86 -- the risc machines (arm & riscv) not only don't support this feature but often don't support *any* unaligned access, atomic or otherwise. With their rise in popularity there will practically not be any cases of this in opensource and with propriety apps the question is that it works or not and working is always preferred.

The search for the correct amount of split-lock misery

Posted Oct 28, 2022 21:31 UTC (Fri) by mrugiero (guest, #153040) [Link]

> I would go as far to argue that throttling an application due to split locks on a single user system is always wrong.

You could, probably accurately, argue that this is always wrong if forced on the user. I.e., you could argue it should be opt-in for single user systems. But some of use would rather want to be able to report these kind of issues. Let alone being the developer of one such game and wanting a fair warning that you may be causing problems. Do you code in a multi-user system most of the time? I don't.

The search for the correct amount of split-lock misery

Posted Nov 8, 2022 8:39 UTC (Tue) by roblucid (guest, #48964) [Link] (1 responses)

No, a performance bug that prevents effective multi-core operation has been detected and should be fixed.
Gamers are concerned about core scaling, the application is sabotaging itself.

The search for the correct amount of split-lock misery

Posted Nov 8, 2022 13:10 UTC (Tue) by Wol (subscriber, #4433) [Link]

The question is simple - if the majority of apps affected by this are games, then this is a user space regression. It needs to be reverted.

Seeing as it appears to be pretty much only gaming systems that are affected, then it most definitely is a user space regression. Especially as a lot of these applications cannot be fixed by the users. And driving gamers to Windows/Apple will be seriously damaging to linux.

And lastly, isn't the (mis)feature itself actually a HARDWARE bug? "Mitigating" the bug by rendering the computer pretty much unusable for its intended purpose isn't a good idea!

Cheers,
Wol


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds