The search for the correct amount of split-lock misery [LWN.net]

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 3:10 UTC (Thu) by mb (subscriber, #50428)
In reply to: The search for the correct amount of split-lock misery by mpr22
Parent article: The search for the correct amount of split-lock misery

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).

to post comments

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.