Announcement

Collapse
No announcement yet.

Faster Booting Via Parallel CPU Bringup Hits A Snag With Older AMD CPUs

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

  • Faster Booting Via Parallel CPU Bringup Hits A Snag With Older AMD CPUs

    Phoronix: Faster Booting Via Parallel CPU Bringup Hits A Snag With Older AMD CPUs

    At the end of last year you may recall the talked about Linux kernel patches for booting systems faster by allowing the parallel bring-up of secondary CPU cores. It's been a while since hearing much about that effort but seems to have hit a snag in that the code is running into problems on early Zen CPUs and older...

    https://www.phoronix.com/scan.php?pa...ingup-AMD-Snag

  • #2
    Black/Whitelisting would really help. Or at least some "force" kernel boot parameter - so that everyone can still check it out. Albeit I don't know when the kernel param are getting read. If it isn't already too late in the boot process.

    Comment


    • #3
      Originally posted by CochainComplex View Post
      Black/Whitelisting would really help. Or at least some "force" kernel boot parameter - so that everyone can still check it out. Albeit I don't know when the kernel param are getting read. If it isn't already too late in the boot process.
      The essential ones get read even beforehand secondary CPUs are brought up. How else would you parse "nosmp".

      Comment


      • #4
        Actually I wonder a bit how this works. I ponder if it would make sense to only wake up as many CPU's as needed during boot and then bring up the rest as e.g. on demand.

        What really is happening? is it DETECTION of CPU's:
        E.g. populating /sys/devices/system/cpu/cpuN where N is the CPU count....

        or is it ENABLING the CPU just as writing 1 to online a CPU that otherwise would be offline
        echo 1 > /sys/devices/system/cpu/cpuN/online again where N is the CPU number

        If it is the later I imagine it would be enough to write 1 to N where N would be a very quick loadaverage number... e.g. if loadavg > 3.0 enable 3+1 CPU's.
        The rest could have been enabled as needed later in the boot process , or even after boot is completed.

        http://www.dirtcellar.net

        Comment


        • #5
          Given the number of CPUs that seem to not work, I'd be concerned about the feature later having an issue with the ones that appear to work, until they understand why and why not.

          Comment


          • #6
            Originally posted by uxmkt View Post
            The essential ones get read even beforehand secondary CPUs are brought up. How else would you parse "nosmp".
            Thx good example!

            Comment


            • #7
              The article is light on details; makes it seem like early Zen and some nebulous "pre Zen" APUs & CPUs are affected.

              It would have been very useful to the casual reader to include a link referencing which "pre Zen" APUs & CPUs have so far been found to be negatively affected by this feature. Right now the casual reader will spend (waste?) time wading through the myriad of posts linked to this subject on the Linux kernel mailing list.

              Has "The Fedora Effect", where anything 5+ years old or more is now considered ancient and ignored, begun to invade the Linux kernel developer corps?

              Comment


              • #8
                CPUID 0xb on Zen! Hum, won't make that bet to get the APIC ID

                Comment

                Working...
                X