Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux

Linux 5.9 Boosts CPU Performance With FSGSBASE Support (phoronix.com) 75

Posted by EditorDavid from the loving-Linux dept.
FSGSBASE support in Linux "has the possibility of helping Intel/AMD CPU performance especially in areas like context switching that had been hurt badly by Spectre/Meltdown and other CPU vulnerability mitigations largely on the Intel side," Phoronix wrote back in August. As it started its journey into the kernel, they provided a preview on August 10: The FSGSBASE support that was finally mainlined a few days ago for Linux 5.9 is off to providing a nice performance boost for both Intel and AMD systems... FSGSBASE support for the Linux kernel has been around a half-decade in the making and finally carried over the finish line by one of Microsoft's Linux kernel engineers...

FSGSBASE particularly helps out context switching heavy workloads like I/O and allowing user-space software to write to the x86_64 GSBASE without kernel interaction. That in turn has been of interest to Java and others...On Linux 5.9 where FSGSBASE is finally mainlined, it's enabled by default on supported CPUs. FSGSBASE can be disabled at kernel boot time via the "nofsgsbase" kernel option.
Today on the Linux kernel mailing list, Linus Torvalds announced the release of Linux 5.9: Ok, so I'll be honest - I had hoped for quite a bit fewer changes this last week, but at the same time there doesn't really seem to be anything particularly scary in here. It's just more commits and more lines changed than I would have wished for.
And Phoronix reported: Linux 5.9 has a number of exciting improvements including initial support for upcoming Radeon RX 6000 "RDNA 2" graphics cards, initial Intel Rocket Lake graphics, NVMe zoned namespaces (ZNS) support, various storage improvements, IBM's initial work on POWER10 CPU bring-up, the FSGSBASE instruction is now used, 32-bit x86 Clang build support, and more. See our Linux 5.9 feature overview for the whole scoop on the many changes to see with this kernel.
This discussion has been archived. No new comments can be posted.

Linux 5.9 Boosts CPU Performance With FSGSBASE Support More

Linux 5.9 Boosts CPU Performance With FSGSBASE Support

Comments Filter:

  • interesting (Score:5, Insightful)

    by Espectr0 ( 577637 ) on Sunday October 11, 2020 @09:13PM (#60596880) Journal

    finally carried over the finish line by one of Microsoft's Linux kernel engineers

    hopefully many will appreciate that companies can change and even if they don't too much, Linux can still benefit a lot from them

    • Re:interesting (Score:5, Insightful)

      by ClueHammer ( 6261830 ) on Sunday October 11, 2020 @10:30PM (#60597038)
      You cannot overlook decades of evil behavior because on one good thing. Microsoft need decades of good things just to be back to neutral. Microsoft has a extremely long way to go before they could be considered good.
    • Comment removed based on user account deletion

      • I'd say enemy #1 to Linux right now would be Google, after all they are the ones letting the cellphone and tablet OEMs make un-upgradeable locked down future e-waste despite the fact that they are running on a Linux kernel and thus would be trivially easy to be opened up and allowed a second life doing other tasks.

        If Google doesn't let handset manufacturers make locked phones then no one will use Android and the only remaining mobile phone OS anyone uses will be iOS.

        If you want to buy unlocked phones, they exist. If you took the cheap way out and got a subsidized phone, you have only yourself to blame, since there are still unlocked Android phones on the market.

        • Comment removed based on user account deletion

          • Blah blah blah fucking blah. The simple fact is that it's not hard to get an unlocked phone. Moto, for example. Your whole assertion was that it's difficult. It isn't. Give over.

            you are gonna sit here with a straight face and try to argue companies like Samsung, LG, and a billion smaller corps are gonna say "We don't need profits for the next few years, if Google doesn't do as we say we'll make our OWN OS with blackjack and hookers!" really? Ask Sailfish how that worked out for them,

            It didn't work out because Android was available under acceptable terms. That may only have been because there was another OS waiting in the wings as a threat, but so what? If so, it worked.

  • has the possibility of helping Intel/AMD CPU performance especially in areas like context switching that had been hurt badly by Spectre/Meltdown and other CPU vulnerability mitigations largely on the Intel side

    And here's a new battery research paper that promises 3x the storage...

    • has the possibility of helping Intel/AMD CPU performance especially in areas like context switching that had been hurt badly by Spectre/Meltdown and other CPU vulnerability mitigations largely on the Intel side

      And here's a new battery research paper that promises 3x the storage...

      It's also bullshit to conflate AMD and CPU while conflating SPECTRE and MELTDOWN, because AMD is not vulnerable to MELTDOWN, only SPECTRE.

  • WTF is FSGSBASE (Score:5, Informative)

    by Ronin441 ( 89631 ) on Monday October 12, 2020 @01:19AM (#60597402) Homepage

    ... which just leaves the question: what actually is FSGSBASE?

    FS and GS are segment registers, that (in Linux and Windows) point to an area of memory. This area is different per-thread, so when you switch threads, FS and GS need to be loaded with new values.

    This new code lets that happen more efficiently, in a way that I don't quite follow, but I think it has to do with not having to change access level from user mode to kernel mode before you execute the instruction.

    https://lwn.net/Articles/76935... [lwn.net]

    • Re:WTF is FSGSBASE (Score:4, Informative)

      by Anonymous Coward on Monday October 12, 2020 @02:27AM (#60597506)
      userlevel instructions that let you change FS and GS, avoiding the need for a system call to do it. this means that the kernel can no longer assume FS/GS have sane values so this is not a trivial change.

      • Re:WTF is FSGSBASE (Score:5, Informative)

        by DamnOregonian ( 963763 ) on Monday October 12, 2020 @02:56AM (#60597552)
        Correct. However the sanity checking is far cheaper than the context switch.

        • It better be, as it needs to be checked all the time, instead of one syscall in that one weird application that needs a memory chroot.

          • Re:WTF is FSGSBASE (Score:5, Informative)

            by DamnOregonian ( 963763 ) on Monday October 12, 2020 @04:22AM (#60597728)
            Generally, the context switch alone costs about 2.2uS.

            That delay is largely due to TLB flushing, etc. I.e., in terms of lost cycles- the faster your machine is, the more expensive that cost is.
            On a 5Ghz machine, for example, the "cost" of a context switch is about 11,000 wasted cycles. On a modern superscalar machine, that generally means a lot more than 11,000 times an instruction could have been executed, were the core not stalled waiting for the caches to flush.

            Context switches are *very* expensive.

            • Generally, the context switch alone costs about 2.2uS.

              That delay is largely due to TLB flushing, etc. I.e., in terms of lost cycles- the faster your machine is, the more expensive that cost is.

              On a 5Ghz machine, for example, the "cost" of a context switch is about 11,000 wasted cycles. On a modern superscalar machine, that generally means a lot more than 11,000 times an instruction could have been executed, were the core not stalled waiting for the caches to flush.

              Context switches are *very* expensive.

              But having to check that condition on every interrupt and scheduled context switch, also easily adds up to tens of thousands of checks.

              And i am pretty sure there are techniques to avoid flushing the TLB when doing simple system calls that continues with the same process. As long as it isn't blocking, which would be much more expensive.

              • Ah, right. it used to be cheaper, but the spectre workaround forces the kernel to flush more to work around Intel bugs.

                • You are correct that it used to be cheaper, but it was still highly expensive.

                  FSGSBASE mitigates quite a bit of that by removing MSR access requirement from the context switch code, so it's faster on both Intel and AMD CPUs, with or without Spectre and Meltdown mitigations.

              • But having to check that condition on every interrupt and scheduled context switch, also easily adds up to tens of thousands of checks.

                Unless it's doing 10s of thousands of checks in between every instance where a userspace process would want to set its FS base, then your scenario isn't realistic.

                And it's not, because TLS is set via FS, and it's highly unlikely that you'll have 10s of thousands of syscalls executed in between every time a thread tries to setup a new TLS, or some JIT wants to use its FS for internal purposes.

                There's a reason this change is happening. The math has already been done. FSGSBASE is superior in performance, e

  • I could be wrong but I think there are some important iouring fixes that are eagerly expected among the non-blocking IO frameworks/libraries.

  • In Case Anyone Is Wondering... (Score:5, Informative)

    by ytene ( 4376651 ) on Monday October 12, 2020 @02:48AM (#60597546)
    I read the OP and each of the linked pages in turn and it wasn't really clear to me what FSGSBASE was or how it worked. Seeing as the entire thrust of the OP suggested it was important, I went looking.

    I came up with this post [lwn.net], captured in the Linux Weekly News archive, which gives a slightly more detailed look at what this patch actually delivers.

    Then there's this page [kernel.org], over at Kernel.org, which goes in to a little bit more detail about the use of the code in managing address spaces and segmentation within the kernel. I'm not even remotely close to a kernel developer, but a close read of this material suggest - to me at least - that this code is a more elegant way of using software to deliver the address space protection that the Meltdown and Spectre vulnerabilities revealed were not working as intended in the physical hardware of Intel and AMD processors.

    It's these improvements to segmentation and address space management that have helped to restore some of the performance that was lost when it became necessary to write software fixes to cover for the CPU design flaws being exploited by Meltdown and Spectre.

    This is probably a bit unfair of me... but in light of the couple of recent /. articles that speculated about Microsoft possibly using the Linux kernel as a foundation for a future version of Windows, I feel obliged to point out that these performance improvements were implemented (as far as we know) in Linux ahead of any proprietary OS.
  • People write about windows on Linux but in the tests biggest gains were on PostgreSQL so I would rather bet on MS SQL. If running MS SQL on Linux uses less Azure resources than on Windows then MS has a strong incentive for even better MS SQL on Linux performance...

  • "one of Microsoft's Linux kernel engineers" (Score:3)

    by BAReFO0t ( 6240524 ) on Monday October 12, 2020 @05:53AM (#60597926)

    There's a line that nobody would have believed a decade ago.

    I checked: Hell officially froze over. They're all ice skating whenever the pigs aren't swarming. I'm sorry. Microsoft Pigs that is!

  • The kernel package is now huge and takes a huge amount of time to compile. I can't help thinking that perhaps the core kernel should be put into its own package so that if there's a change in the core it can easily be downloaded and built without having to rebuild all the driver code along with it. Yes, this will make matching up compatible driver packages with kernel core an issue but perhaps its something that should be looked in to.

    • Re:Is it time to split core kernel from drivers? (Score:4, Informative)

      by DamnOregonian ( 963763 ) on Monday October 12, 2020 @06:13AM (#60597970)
      lolwut?

      The kernel is modular.
      Distributions ship what they need, people build what they want.
      If you want to tack on out-of-tree modules to your currently running kernel, there's DKMS.
      Symbol table fingerprinting is a thing to ensure compatibility.

      Ya, we'll look into it though.

  • We're still putting band-aids around our segment register architecture.

Slashdot Top Deals

You know you've landed gear-up when it takes full power to taxi.

Close