Announcement

Collapse
No announcement yet.

AMD Details "SQUIP" Side Channel Vulnerability For Zen's Execution Unit Scheduler

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

  • #41
    Originally posted by PublicNuisance View Post
    Looks like switching back to an FX-9590 is paying dividends for me already. Got rid of the PSP and now this.
    But how much performance did you lose in going back to a FX-9590? Did you "Before & After" benchmark your changes?

    Comment


    • #42
      Originally posted by geearf View Post


      What's the benefits of having those units in numbers bigger than 1 instead of just splitting them into separate cores? I assume you have different numbers for different types of units so that probably wouldn't really work out though.

      Thank you!

      Oh wow, is 8 the optimal number for most cases? Can you tweak it, whether in BIOS or on the fly, to a smaller number if it works out better?

      Thanks!
      The link to the IBM document (short and clearly written, IMHO as a non-IBM user) hidden behind the words "can make use of it." shows that it can be adjusted by the user on both PPC and AIX platforms.

      IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

      Comment


      • #43
        Originally posted by erniv2 View Post

        That does not sound like a firmware bug, if smt is enabled in the uefi it will fireup all the logical cores when resuming from hibernation, but since linux expects only the real cores they dont get properly initalized on resume, because linux assumes the last running state is ok, wich then conflicts with the acpi/uefi settings and some of your cores stay running in realmode instead getting switched to protected or long mode when resuming, resulting in the higher power draw because they wait for instructions that are not comeing, running your script then tells them hey here are instructions we know you are there switch to long mode, and when turning off smt it tells them we dont need you just shut up, that´s one of those acpi misbehaviors or things that happen when you dont do a proper reboot.
        Not hibernate, but suspend (to RAM). Hibernate actually works without the workaround because Linux does the same thing (boot all logical CPUs, then offline the undesired ones) itself, same way as it does on regular boot. AFAIK, in case of suspend, it's the firmware's job to restore the state of the hardware, but if the issue is more widespread, a kernel workaround could be a good idea.

        Comment


        • #44
          Originally posted by archkde View Post

          Not hibernate, but suspend (to RAM). Hibernate actually works without the workaround because Linux does the same thing (boot all logical CPUs, then offline the undesired ones) itself, same way as it does on regular boot. AFAIK, in case of suspend, it's the firmware's job to restore the state of the hardware, but if the issue is more widespread, a kernel workaround could be a good idea.
          Hibernate writes the OS state to a file, shutting down the hole system. Suspend to RAM keeps the Ram clock alive and refreshes the ram so the content does not get lost, in this described case the Kernel actually does a Boot routine for the Hibernate case while in the S3 case it does not and causes the behavior described above, wich is wierd actually i would have thought the other way around cause some settings may be lost in Hibernate but with S3 they should stay in ram.

          And no it´s not the firmwares job to restore the OS state, the firmware is there to set your Hardware to a running state that can boot an OS, if your Uefi says i have 6c/12t we got 12 CPU running and you put a kernel parameter nosmt you run only 6 CPU, so my described behavior still stays 6 CPUS run and 6 CPUS run in the Bios mode Realmode this has to do with oh so good old x86 compatibility, the Realmode is what waits for Bios calls or old DOS, that core runs full throttle waiting for input, then you switch up to Protected (32Bit) here the OS allready has control over the idle calls etc., so the described power draw when 6 Threads run and run waiting, long mode is the x64 bit version the OS has full Control.

          The implications here are that i tend to call it a kernel BUG because the kernel does not take the prior Bootline command into consideration and does not spin up the Threads that should not run and shut them down after, you circumvent this BUG with said script, Spin them up and shut them down shortly after and you get back the expected behavior.

          This is partly old knowledge so i can´t give any garanties.

          It´s a pain in the ass if you have a Laptop, it´´s practically nonexistent if you use a 24/7 desktop, maybe thats why nobody discovered it before.

          Reboot your System let the firmware set it to a sane state and dont mess with the kernel parameters unless you need to......
          Last edited by erniv2; 10 August 2022, 06:12 PM.

          Comment


          • #45
            Originally posted by NotMine999 View Post

            The link to the IBM document (short and clearly written, IMHO as a non-IBM user) hidden behind the words "can make use of it." shows that it can be adjusted by the user on both PPC and AIX platforms.
            https://developer.ibm.com/articles/p...-perf-for-db2/
            That's nice!
            It makes me wonder if it'd be nice to be able to do on AMD systems as well per core.

            Comment


            • #46
              Originally posted by NotMine999 View Post

              But how much performance did you lose in going back to a FX-9590? Did you "Before & After" benchmark your changes?

              Probably a lot. I used to run a FX8320 @ 4.8GHz before and when I upgraded to a R7 1700 the performance uplift was very noticeable, even with the Ryzen at stock frequencies. Especially for light threaded frequency heavy workloads.

              Comment


              • #47
                Originally posted by WannaBeOCer View Post

                What a fanboy, getting defensive because AMD can’t communicate or fix software issues. I owned a RX 5700 for 8 days and returned it with-in my return policy because I wasn’t going to get stuck with a non-functional GPU.

                AMD’s windows drivers have always been garbage for new architectures. It was a year until they finally acknowledged the issues. They started getting blasted by tech tubers they ignored the issue to sell their cards. Then they finally started releasing proper collection tools in their drivers. Hopefully with the bug collection tools they won't run into this issue again with which ever architecture replaces RDNA. AMD's GCN drivers were so bad, once AMD figured out how to properly optimize them fanboys started calling it "AMD's Fine Wine." That's why Polaris/Vega weren't gaining any major improvements after years aside from game day drivers.





                The RX 5000 series came out a year and 2 months before Covid.
                Don't know where you are getting the idea I am a fanboy. I run a GTX 1070 and a RX 6600 XT. Intel i7 7th gen and AMD 5800X so I have a mixed bag. You seem to forget that ppl with issues have the loudest mouth and are a minority while the majority of ppl don't have issues whatsoever.

                The releasedate was July 7, 2019 and Covid was worldwide februari 2020, if you want to be so pedantic get your facts straight.

                Those youtube video's are from jan/feb 2020.
                Last edited by DRanged; 10 August 2022, 09:55 PM.

                Comment


                • #48
                  Originally posted by piotrj3 View Post

                  I strongly disagree with that statement. Ideally all those companies have diffrent intend then you, they are not user friendly. So your intention is to not join any teams and just pick best tool for your job.

                  Like if you need open source driver for linux with wayland - you know where to go.
                  If you need scientific/high computation usage with CUDA - you also know where to go.
                  You need budget modern PC for general usage - you know also where to go.
                  You need rendering farm - you also know where to go.
                  You need higher stability platform that won't cause you USB dropout issues, or PCI-E you know who to pick.
                  You want a platform with better upgrade options long term you also know who to pick.

                  I had initially Ryzen 3600 (because back then it was good choice), and after I upgraded to Ryzen 5800X3D because it was good upgrade option for my platform. But if i buided PC from scratch I would actually go for something like 12600/12700 CPU.
                  I also have nvidia GPU because i do use CUDA/computationally intensive stuff.

                  Literally stop being fanboys. Pick what in right time best fits your usage.
                  Sad thing is the fact your blinded to your own tribe. Your own community. The tribe of "non tribes." You all are united as a single tribe of being against tribes. You all have your own circle jerk.

                  It's like watching the "non fanboy" railing against amd while promoting only using Intel and Nvidia and will never use amd. It's hilarious. "Welp, it's bad to use amd, guess I'll use their competition instead." How convenient. Can hide being a fanboy while shilling for the other side

                  "I'm against tribes so join me in my crusade against tribes" "I hate being a fanboy so join me in my hatred for one brand while promoting the other brand." God I love manipulation. Works wonders. Then you have the "I'm a fan of those against fanboys." You quite literally have people cheering on, being a fan for those who are against fanboys. The fanboys against fanboys. It's hilarious.

                  Now I'm going to ignore this thread because I honestly don't want to see the level of mental gymnastics any responses will be by the non tribe, tribe, and non fanboy, fanboys.

                  Birds of a feather flock together. People with similar beliefs, interest, anything that makes one person similar to another, will come together. Yes, even those that are against something, will unite together with others who against the same thing.
                  Last edited by middy; 11 August 2022, 04:12 AM.

                  Comment


                  • #49
                    Originally posted by middy View Post
                    Sad thing is the fact your blinded to your own tribe. Your own community. The tribe of "non tribes." You all are united as a single tribe of being against tribes. You all have your own circle jerk.
                    The good old "lets pretend like everything in life is a circlejerk and I'm above it all"

                    Originally posted by middy View Post
                    It's like watching the "non fanboy" railing against amd while promoting only using Intel and Nvidia and will never use amd. It's hilarious. "Welp, it's bad to use amd, guess I'll use their competition instead." How convenient. Can hide being a fanboy while shilling for the other side
                    Not sure where you saw that in the thread? You can both be not loyal to multi billion dollar corporations and still use their products, you know.

                    Originally posted by middy View Post
                    Now I'm going to ignore this thread because I honestly don't want to see the level of mental gymnastics any responses will be by the non tribe, tribe, and non fanboy, fanboys.
                    "I'm right you're wrong and won't listen to any responses because I know I'm right" *plugs ears*

                    (Not sure if that post was meant as bait, if it was then I guess you got me.)
                    Last edited by fong38; 11 August 2022, 07:01 AM.

                    Comment


                    • #50
                      Originally posted by archkde View Post

                      Yes, it's pretty easy to explain. When I suspend the system while some logical CPU is offline, the firmware will put that CPU in a very shallow idle state once the system resumes again. This leads to massively increased power usage. So I have a script that enables and immediataly disables SMT again on resume, which works around the bug because Linux puts the offline CPU in the deepest idle state properly.
                      Ah. I think suspend being affected by SMT is firmware-related. I don't think it's a bug, but I'm curious on what exactly happens with SMT on/off in the firmware.

                      I have an ASUS PRIME-X470 PRO motherboard, and for the SMT option the BIOS specifically mentions S3/Sleep not functioning when cores are removed. In AMD CBS there's a similar note, and that implies whatever is happening is intentional and done by AMD.

                      Comment

                      Working...
                      X