Announcement

Collapse
No announcement yet.

Linux Preps Hybrid SMP Fix To Avoid Upcoming Laptops Appearing As 11 Socket Monsters

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

  • Linux Preps Hybrid SMP Fix To Avoid Upcoming Laptops Appearing As 11 Socket Monsters

    Phoronix: Linux Preps Hybrid SMP Fix To Avoid Upcoming Laptops Appearing As 11 Socket Monsters

    A fix is on its way to the mainline Linux 6.4 kernel and also marked for back-porting to existing stable kernel series to fix x86 topology reporting for Intel Hybrid systems. The topology bug within the kernel becomes more pronounced for Meteor Lake laptops where currently internal Intel test laptops can report the systems having 11 CPU sockets rather than the proper number of cores all contained within one CPU socket...

    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
    Spinal Tap's Nigel Tufnel as a neckbeard GNU/Linux bro (who probably runs Arch, by the way):

    Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and...
    Marty DiBergi: Oh, I see. And most laptops go up to ten?
    Nigel Tufnel: Exactly.
    Marty DiBergi: Does that mean it's faster? Is it any faster?
    Nigel Tufnel: Well, it's one faster, isn't it? It's not ten. You see, most blokes, you know, will be processing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your laptop. Where can you go from there? Where?
    Marty DiBergi: I don't know.
    Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
    Marty DiBergi: Put it up to eleven.
    Nigel Tufnel: Eleven. Exactly. One faster.
    Marty DiBergi: Why don't you make ten a little faster, make that the top number and make that a little faster?
    Nigel Tufnel: [pauses] These go to eleven.​

    Comment


    • #3
      Hehe.

      Working on a GNU farm
      Trying to raise some hard disks
      ...

      Comment


      • #4
        Why do we even need SMT with the security risk it is for side channel attacks? Intel and AMD can put enough physical cores on a chip nowadays to make SMT not needed. Some security related projects have disabled SMT for years now like OpenBSD since the 6 series releases.

        Comment


        • #5
          Originally posted by kylew77 View Post
          Why do we even need SMT with the security risk it is for side channel attacks? Intel and AMD can put enough physical cores on a chip nowadays to make SMT not needed. Some security related projects have disabled SMT for years now like OpenBSD since the 6 series releases.
          As always, it depends on your threat model. Some use cases do not need to disable SMT, and some actually colossally benefit from it.
          After all, in a perfect scenario, you can double your throughput with two way SMT.

          Comment


          • #6
            I would say do away with SMT and P cores completely and just release a high E core count CPU. for the desktop, like that rumored 128 E-core only Xeon that's supposedly arriving in 2024.

            Comment


            • #7
              Put more real cores, make programming languages able to use them even by an extremely dumb monkey coder and profit for it. And meanwhile, make a CPU architecture more similar to FPGA and make specialized chips unnecessary.

              Comment


              • #8
                Originally posted by timofonic View Post
                Put more real cores, make programming languages able to use them even by an extremely dumb monkey coder and profit for it. And meanwhile, make a CPU architecture more similar to FPGA and make specialized chips unnecessary.
                I had some algorithm which was slow. I found C++'s std::thread API so easy to use I couldn't believe how quickly I was able to adapt the algorithm and now all cores are pegged at max when this runs.

                Maybe most things aren't parallelizeable, but this is graphics,and graphics are highly parallelizable. Maybe this should be running in the GPU,actually. But I'm finding the latest APIs from OpenGL and Vulcan neigh on inscrutable, unfortunately. And I did a bunch of OpenGL work back in the days of the fixed-function pipeline.

                Comment


                • #9
                  Originally posted by sophisticles View Post
                  I would say do away with SMT and P cores completely and just release a high E core count CPU.
                  You will quickly start to dislike such a system, because there will inevitably be something that is running single-threadedly (because the design of current implementations just ain't better) and everything else is waiting on it. Like 'grep -r blah /archive | sort | pixz ...`

                  Comment

                  Working...
                  X