Announcement

Collapse
No announcement yet.

A 20 Year Old Chipset Workaround Has Been Hurting Modern AMD Linux Systems

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

  • #41
    Originally posted by ATLief View Post

    Is no one else going to say it? Ok.

    ...They should rewrite the Linux kernel in Rust.
    Since the Kernel has some experimtal support for Rust written drivers, it might be possible in the far future. I dont know how fissible it is, but maybe rewriting parts/modiles peu a peu could transform the kernel in the longrun. And rewriting those parts would force people to completly reassess existing code. Albeit not breaking compatibly at once. On the other hand maybe some new concepts wouldn't be incorporated to the code base due to obvious incompatiblities.

    Comment


    • #42
      Originally posted by RealNC View Post
      I hope this gets backported to LTS. It would be interesting to test whether or not this is the source of the performance issues I have with some emulators ever since I upgraded from my old Intel system to a 3700X one. The emulators will run full-on for like 2ms or so to emulate one frame, then idle the rest of the time until the next emulated vblank. If I don't use GameMode to switch from the schedutil to the performance governor, I get sound dropouts and animation hiccups.
      No, if anything, looks like this will make the situation worse in combination with the schedutil governor, because another user reported the following with this fix applied:

      After this patch i have a lot of slowdowns on Yuzu that I didn't have before.

      amd-pstate + schedutil + 5950x​
      Phoronix: Linux 6.0 Merges The AMD Performance Fix For The Old "Dummy Wait" Workaround This morning I called attention to some pending work around a 20 year old chipset workaround in the Linux kernel had been hurting modern AMD systems by erroneously still applying the change to modern hardware. Fortunately, that

      Comment


      • #43
        Originally posted by ATLief View Post

        Is no one else going to say it? Ok.

        ...They should rewrite the Linux kernel in Rust.
        Rust really has become the new "I use arch btw"...

        Comment


        • #44
          This is how I have been fixing that performance issue within CoreFreq
          1. Boot kernel blacklisting any cpu idle driver
          2. Start my kernel module "corefreqk.ko" with parameters to register my own assembly idle loop. See Q&A
          3. Default Idle Route is for Zen, an I/O-Wait; AMD families 16h & prior, with HLT; MONITOR/MWAIT for Intel
          4. ​​​​​Can change Route at any time from the CLI "corefreq-cli" while monitoring freq, C-state entries, voltage, power impacts
          github.com/cyring/CoreFreq
          CoreFreq is a CPU monitoring software designed for the 64-bits Processors. - GitHub - cyring/CoreFreq: CoreFreq is a CPU monitoring software designed for the 64-bits Processors.
          Last edited by cyring; 27 September 2022, 09:56 AM.

          Comment


          • #45
            Originally posted by coder View Post
            No, IBS refers to Instruction-Based Sampling, which is a hardware-assisted profiling mechanism.

            https://www.phoronix.com/news/Linux-...IBS-Perf-Tools
            yeah, but I couldn’t resist..
            it does seem, according to the article, linux suffered an irritable bowel with amd..
            someone dug into the “bowels” and found out why and performed some minor surgery to fix it.

            shrug. Was a joke fer chrissakes.

            Comment


            • #46
              Some of you may recall the early Ryzen CPUs had an issue where they would just randomly freeze up after hours or days under Linux. It only seemed to happen when the system was very idle. I said half-jokingly that this wasn't seen on Windows because it never gets that idle. I then heard through the grapevine that people inside AMD thought that may indeed be the case.

              I'm no expert, but I now reckon this kernel bug was causing it to happen more often than it otherwise would have. Maybe it's just as well. If it hadn't happened so frequently, AMD may have taken much longer to fix it.​

              Comment


              • #47
                Originally posted by yump View Post

                Yeah, I would really like to see details of how this was found.
                He likely had the idea to check for this kind of issue and devised a way to check for it. I suggest emailing him to ask. I would be interested in hearing what he says.

                Comment

                Working...
                X