Announcement

Collapse
No announcement yet.

Linux 5.19 Frowns On x86/x86_64 Late Microcode Loading - "It's Just Lottery & Broken"

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

  • Linux 5.19 Frowns On x86/x86_64 Late Microcode Loading - "It's Just Lottery & Broken"

    Phoronix: Linux 5.19 Frowns On x86/x86_64 Late Microcode Loading - "It's Just Lottery & Broken"

    A last minute change sent in on Sunday and merged prior to Linux 5.19-rc1 disables late microcode loading by default for x86/x86_64 processors over its sad state of affairs...

    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
    thankfully t2 Linux support early microcode loading out of the box: https://www.youtube.com/watch?v=ev1-k2PDGpg

    Comment


    • #3
      I can't imagine why you'd want to load the proper microcode after your CPU starts doing stuff...

      Comment


      • #4
        Originally posted by bug77 View Post
        I can't imagine why you'd want to load the proper microcode after your CPU starts doing stuff...
        It might be relevant for high availability applications. Where having to restart the servers for a microcode update is enough to make a (unwelcome) difference.
        But Linus is right: late microcode loading should not come at the expense of a less stable system.

        Comment


        • #5
          Originally posted by Rabiator View Post
          It might be relevant for high availability applications. Where having to restart the servers for a microcode update is enough to make a (unwelcome) difference.
          But Linus is right: late microcode loading should not come at the expense of a less stable system.
          I doubt high availability is relevant to this particular patch set, however. Most built-for-many-nines hardware has the ability to cycle nodes in and out of service without interfering with the overall availability. This means late loading of microcode is still irrelevant. Trying to load microcode on-the-fly with consumer or lower-end server hardware is just asking for trouble as the patch notes (and you) state. The race conditions could indeed be catastrophic.

          Comment


          • #6
            This is mostly a thing for people refusing to use an initrd.

            Comment


            • #7
              Originally posted by s_j_newbury View Post
              This is mostly a thing for people refusing to use an initrd.
              Why would people refuse to use an initrd? Why do you suppose someone would prefer the alternative?

              Comment


              • #8
                Originally posted by jbranso View Post

                Why would people refuse to use an initrd? Why do you suppose someone would prefer the alternative?
                Single kernel image.. I used to do that decades ago when playing around with Linux, but honestly it was just laziness.

                Comment


                • #9
                  Originally posted by s_j_newbury View Post
                  This is mostly a thing for people refusing to use an initrd.
                  You can avoid using an initrd and do early loading of microcode with the right kernel command line.

                  Comment


                  • #10
                    Originally posted by carewolf View Post
                    Single kernel image.. I used to do that decades ago when playing around with Linux, but honestly it was just laziness.
                    I'm not sure if you mean having a single file or having a generic build that works everywhere, but in the first case I think you can bundle the initrd in your regular kernel, and for UEFI you can make a PE that includes both the kernel and initrd, there's a guide in Lennart's blog (he promotes it for systemd-boot, but should work regardless).

                    Comment

                    Working...
                    X