Announcement

Collapse
No announcement yet.

Linux 5.19 To "Make Life Miserable" In Slowing Down Bad Behaving Split-Lock Apps

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.19 To "Make Life Miserable" In Slowing Down Bad Behaving Split-Lock Apps

    Phoronix: Linux 5.19 To "Make Life Miserable" In Slowing Down Bad Behaving Split-Lock Apps

    Back in 2020 Intel engineers working on the Linux kernel added split lock detection to provide a warning when an atomic operation spans multiple cache lines and requires a global bus lock for atomicity. A warning is now deemed not useful enough so instead the intent moving forward is to "make life miserable" for such misbehaving user-space applications by slowing down the performance with hopes of the app developers better handling their code...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    "We don't break user-space!"
    (But we are certainly giggling with glee when crippling it...)

    Seriously though, hopefully this won't adversly affect old but still useful software that will never get updated to comply with this kernel policy recommendation, thus suffering the performance-penalty from here on out.

    Comment


    • #3
      Send Samuel L Jackson to the houses of all split lock violators.

      Comment


      • #4
        If the Linux community would've been so united to make the life miserable for Nvidia and its users, Nvidia woul've been forced sooner to open source their drivers.

        Comment


        • #5
          Originally posted by Linuxxx View Post
          "We don't break user-space!"
          (But we are certainly giggling with glee when crippling it...)

          Seriously though, hopefully this won't adversly affect old but still useful software that will never get updated to comply with this kernel policy recommendation, thus suffering the performance-penalty from here on out.
          You can always disable the split lock detection in those cases.

          Comment


          • #6
            Originally posted by Danny3 View Post
            If the Linux community would've been so united to make the life miserable for Nvidia and its users, Nvidia woul've been forced sooner to open source their drivers.
            I think the first who will suffer from this change will be NVIDIA horrible drivers. For example, not so long time ago I found out who was responsible for 1-2 second lag on my notebook, when WINE was updating prefix. The lag is so horrible that even cursor does not move at that time. I thought it was WINE until for some reason I booted into my system with NVIDIA drivers unloaded (Optimus hell yeah) and using only Intel GPU system was smooth and responsible during that operation. I am just looking forward to finally build my PC with AMD only and sell this notebook to some happy kid who will game Windows on it.

            Comment


            • #7
              As long as it isn't default, cool. Sounds great for a debug option while kind of sucky for default. Fatal could be a good debug option, too.

              Now, if this was tied to something like a sysctl or an env variable so it could be set to off or warn when running a known troublesome program or a program that'll never be updated then sequential might actually make for a decent default option. I'd be nice to at least be able to submit bug reports of "it's acting kinda funky with split locks" while then being able to tweak a launch parameter somewhere like the...well...I'm on KDE so I guess it's the three dots and an arrow menu so I could go about my business without it acting kinda funky.

              Comment


              • #8
                Are there any examples of known offending programs? Not sure if this would be a big problem to be enabled by default, but if it isn't, there isn't much point.

                Comment


                • #9
                  Originally posted by Linuxxx View Post
                  Seriously though, hopefully this won't adversly affect old but still useful software that will never get updated to comply with this kernel policy recommendation, thus suffering the performance-penalty from here on out.
                  To my understanding, it seems like it mostly affects poorly written software, not necessarily old. I don't think there are a lot of old programs still in use that are also very demanding of resources.

                  Originally posted by skeevy420 View Post
                  As long as it isn't default, cool. Sounds great for a debug option while kind of sucky for default. Fatal could be a good debug option, too.
                  Well, if it's not on by default then nobody will turn it on, and therefore it's useless. The fact it likely won't be on by default means it will probably just fade into obscurity with people thinking "wtf is this option and why would I ever enable it?". Distros aren't going to willingly lose performance just so crappy developers are motivated to do a better job.
                  Now, if this was tied to something like a sysctl or an env variable so it could be set to off or warn when running a known troublesome program or a program that'll never be updated then sequential might actually make for a decent default option. I'd be nice to at least be able to submit bug reports of "it's acting kinda funky with split locks" while then being able to tweak a launch parameter somewhere like the...well...I'm on KDE so I guess it's the three dots and an arrow menu so I could go about my business without it acting kinda funky.
                  That I agree with.

                  Comment


                  • #10
                    Originally posted by sinepgib View Post

                    You can always disable the split lock detection in those cases.
                    Thanks for reminding me, Captain Obvious!

                    Now, let's say an obscure & baddly written closed-source Windows game (there are rumors floating around the internet that those actually can & do exist) running under Proton suddenly starts tanking in performance for the average (non-Linux) user of a Steam Deck after an update to the "firmware" (people are actually calling SteamOS like that out there) of the device:
                    Who do you think that person is going to blame for that?
                    And what would be your suggestion to such a person?
                    Go ahead and fix the problem by disabling the split-lock detection (ThE HeLL iS ThaT???) via kernel boot parameter on the command line, just so that it can be erased during the next update to the immutable "firmware" of the Steam Deck?

                    Certainly, fun times ahead...

                    Comment

                    Working...
                    X