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

The search for the correct amount of split-lock misery

Posted Oct 28, 2022 22:18 UTC (Fri) by marcH (subscriber, #57642)
In reply to: The search for the correct amount of split-lock misery by Vipketsh
Parent article: The search for the correct amount of split-lock misery

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

to post comments

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.