Announcement

Collapse
No announcement yet.

Linux 5.18 Unifying Two More Portions Of AMD & Intel Code

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

  • Linux 5.18 Unifying Two More Portions Of AMD & Intel Code

    Phoronix: Linux 5.18 Unifying Two More Portions Of AMD & Intel Code

    Thanks to the nature of open-source and independently-controlled projects like the Linux kernel, there is already much code sharing among competitive hardware vendors in areas where applicable. Much of the Linux kernel's x86/x86_64 code is shared between AMD and Intel (and VIA, Centaur, and Hygon for that matter) where relevant while due to different supported features and implementation differences there is divergence at times. With Linux 5.18 there are two features currently with unique AMD and Intel code paths that are working towards more unification...

    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
    Code:
    /sys/devices/system/cpu/cpu*/topology/ppin
    For anyone else who was wondering, reading this file will be a privileged operation.

    Edit: AAAAAAAAAAAA

    One begins to wonder whether "preferred form for making modifications" in the GPL means Greg K-H needs to put his editor config in git =P

    (Er, Greg K-H chosen for comic effect, not by git blame. I didn't actually check who is responsible for the macro magic.)
    Last edited by yump; 22 March 2022, 01:00 AM.

    Comment


    • #3
      Hope the same happens to ARM Code!

      Comment


      • #4
        Btw, who maintains the shared code? Intel or AMD? Aren't there arguments or attempts to sabotage other's products with code that is less performant for the other?

        Comment


        • #5
          "...at least some motherboard BIOS do allow for PPIN reporting to be disabled."

          It does seem weird to me that the bios has the ability to mask hardware numbers off from the OS. After all, it's just software and these days should just load the OS and get out of the way.

          Of course, in reality BIOSs are a fucked-up wonderland of bad ideas. All the way from horrible design patterns in UEFI, to the security nightmare that is SMM. Just another reason x86 needs to die.

          Comment

          Working...
          X