Announcement

Collapse
No announcement yet.

AMD Updates Linux Patches For Lowering Idle Exit Latency

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

  • AMD Updates Linux Patches For Lowering Idle Exit Latency

    Phoronix: AMD Updates Linux Patches For Lowering Idle Exit Latency

    Last month an AMD engineer began posting Linux kernel patches so the kernel prefers the MWAIT instruction over HALT for lowering the CPU idle exit latency. Preferring MWAIT over HALT has been something Intel CPUs on Linux have preferred going back to the Core 2 days and indeed with modern AMD CPUs there is significant advantages to lowering the exit latency in doing so for the idle code. This morning the latest iteration of the work was posted...

    https://www.phoronix.com/scan.php?pa...refer-MWAIT-v3

  • #2
    Is there something switched up? MWAIT values are larger than HALT.

    Comment


    • #3
      Originally posted by Anux View Post
      Is there something switched up? MWAIT values are larger than HALT.
      That graphic in the article is of the context switching perf, not latency. See the mailing list post for the other latency numbers.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        Ah nice and there are also nano seconds in the patch. THX

        Comment


        • #5
          It's a nice move from AMD; using Zen architectures, having the number of cycles elapsed in deep idle states like Core and Package C6, (Intel is providing them through MSR registers) would be awesome.

          For unfound reasons, yet, my observed energy measurements in CoreFreq, using RAPL registers, reveal a per Core power increased when the kernel loop is idling in MONITOR/MWAIT versus HALT or I/O wait.
          ​​​​​

          Recommended to check the associated bit state in HWCR before executing MWAIT or Processor freeze.
          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.

          Comment


          • #6
            Originally posted by cyring View Post
            For unfound reasons, yet, my observed energy measurements in CoreFreq, using RAPL registers, reveal a per Core power increased when the kernel loop is idling in MONITOR/MWAIT versus HALT or I/O wait.
            ​​​​​
            As far as i understand it, with MWAIT you can specify a "C-state" to enter, with HLT C0 is entered.. Probably a tradeoff between wakeup time and power saving. The MWAIT patch might not enter such a deep sleep state than the HLT instruction did before?

            Comment


            • #7
              Originally posted by Spacefish View Post

              As far as i understand it, with MWAIT you can specify a "C-state" to enter, with HLT C0 is entered.. Probably a tradeoff between wakeup time and power saving. The MWAIT patch might not enter such a deep sleep state than the HLT instruction did before?
              Trying various hints did not make a difference.
              But I noticed that the MONITOR/MWAIT power overhead is barely the same as Core C6 state (CC6) disabled
              • HALT + CC6 enabled: 0.1W (Cores) and 16W (package)
              • HALT + CC6 disabled: 4W (Cores) and 32W (package)
              • MONiTOR/MWAIT + CC6 enabled = 4W (Cores) and 32W (package)
              • MONITOR/MWAIT + CC6 disabled = same as above
              • I/O wait follows HALT results
              2022-05-11-031050_644x1012_scrot.png

              Comment

              Working...
              X