|
|
Log in / Subscribe / Register

The search for the correct amount of split-lock misery

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 2:25 UTC (Thu) by kschendel (subscriber, #20465)
Parent article: The search for the correct amount of split-lock misery

The sysctl knob seems a good idea, but IMO it's backwards -- the name is "split_lock_mitigate", so to mitigate, it should be set to 1. To cause pain, mitigation is turned off, ie should be set to zero.

Bikeshedding, I guess, but still.


to post comments

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 13:00 UTC (Thu) by tamara_schmitz (guest, #141258) [Link]

I think it's already as you described it:

0 Disables the misery mode - just warns the split lock on kernel log.
1 Enables the misery mode (this is the default) - penalizes the split lockers with intentional performance degradation.

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 15:53 UTC (Thu) by WolfWings (subscriber, #56790) [Link] (2 responses)

In this case the mitigation is preventing impact to the rest of the system, which indeed is what "1" does. It directly penalizes anything that triggers split-cacheline-atomic scenarios by forcing it to eat a 10ms pause in it's next scheduling.

"0" disables the mitigation, allowing any single application to hog the bus for it's own locks and arbitrarily DDoS the rest of the system as a result.

The search for the correct amount of split-lock misery

Posted Oct 23, 2022 1:11 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

It's not a DDoS, it's just a regular DoS. There's only one system involved.

More to the point, this whole idea is clownshoes anyway. The purpose of the kernel is to serve userspace, not to tell userspace what to do. If userspace wants to hurt its own performance, that's the sysadmin's* problem. For some configurations, it might make sense to allow the sysadmin to block or restrict split-lock operations, but it should function like an rlimit, not a system-wide "block first, ask questions later" flag.

* If there is no sysadmin, that means it's a single-user system and the "problem" is even more nonsensical.

The search for the correct amount of split-lock misery

Posted Oct 23, 2022 17:27 UTC (Sun) by marcH (subscriber, #57642) [Link]

> The purpose of the kernel is to serve userspace, not to tell userspace what to do.

No, the purpose of the kernel is to protect userspace from each other (some single application systems don't even have a kernel)

> If userspace wants to hurt its own performance, that's the sysadmin's* problem.

Default settings matter A LOT and it's really good to see overbusy maintainers spending so much time discussing and getting them right.

> > Affected gamers will have to set the new knob appropriately, but knowing which sysctls to tweak could be said to be part of being a true God of War.

Happy ending:
- The "bug" will not go unnoticed and new applications will avoid it
- Old applications will run too after a few minutes searching the Internet.

Very delicate trade-off perfectly found.

The search for the correct amount of split-lock misery

Posted Oct 21, 2022 4:08 UTC (Fri) by ballombe (subscriber, #9523) [Link]

Well, there should exist a mitigation that still allow God of War to run with decent performance.
The current one was made painful by design, not by necessity. This is a false dilemma.


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