Announcement

Collapse
No announcement yet.

Cleaning Up A Mess: Linux 6.9 Likely To Land Rework Of x86 CPU Topology Code

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

  • Cleaning Up A Mess: Linux 6.9 Likely To Land Rework Of x86 CPU Topology Code

    Phoronix: Cleaning Up A Mess: Linux 6.9 Likely To Land Rework Of x86 CPU Topology Code

    Longtime Linux kernel developer Thomas Gleixner with Intel-owned Linutronix has been spending much time over the past several months reworking the Linux kernel's x86 CPU topology evaluation code. This is to clean-up a mess of aging kernel code as well as some areas of the code being incorrect in today's era of hybrid Intel Core processors with a mix of P / E cores with the E cores lacking SMT/HT and thus throwing off prior kernel assumptions. With the code now queued up in a TIP branch today, it looks like that CPU topology rework could be good to go with Linux 6.9...

    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
    Thank intel and its fake marketing cores. But I'd say 2 types of fake cores is simply not enough. It has to be a real maze, a paradoxical issue for the OS to schedule work properly.

    Comment


    • #3
      Originally posted by ddriver View Post
      Thank intel and its fake marketing cores. But I'd say 2 types of fake cores is simply not enough. It has to be a real maze, a paradoxical issue for the OS to schedule work properly.
      so true, bug.shittle is the mess, not the kernel code

      Comment


      • #4
        This is valuable work that has nothing to do with pathetic fanboy issues.

        Its also particularly useful that this work is happening now because it’s not inconceivable that CPUs drop HT entirely in the future.

        Comment


        • #5
          Thanks Thomas Gleixner. I always appreciate good code refactoring!

          Comment


          • #6
            I've said it before, Thomas Gleixner is a hero, it's very hard to take and rewrite code like this... He did the same with the interrupt subsystem a while ago.

            Comment


            • #7
              Originally posted by ddriver View Post
              Thank intel and its fake marketing cores. But I'd say 2 types of fake cores is simply not enough. It has to be a real maze, a paradoxical issue for the OS to schedule work properly.
              I think heterogeneous CPUs are a good thing. They're only an issue when they're not managed correctly, like when SMT isn't managed correctly and we lose performance. IMO, Intel should have done the LP cores long before the E cores. They need that energy efficiency and the LPs are excellent for that. The biggest issue with Intel's implementation are the mixed instruction sets, though.
              Last edited by Mitch; 17 February 2024, 04:31 AM. Reason: Clarity, spelling

              Comment


              • #8
                Originally posted by Mitch View Post

                I think heterogenous CPUs are a good thing. They're only an issue when they're not managed correctly, like SMT. IMO, Intel should have done the LP cores long before the E cores. They need that efficiency and the LPs are excellent for that. The biggest issue with Intel's choices are the mixed instruction sets though.
                Well, if you like performance unpredictability and discrepancy core to core, that's your thing.

                Usually when people state that they "think" something is a "good" thing, that's followed by some type of elaboration on said "thought process".

                Cuz the way you currently put it, seems like it is more of a belief than anything else.

                And let me reassure you, there are ZERO good technical reasons for intel to do that, they just failed time and time again to compete in the core count department. They didn't do that because it is better for the consumer, and in fact did it out of the overly brilliant and technical peak ability of certain people to compare integer numbers to determine which product is "better".

                And now, as a result of that, we have 8 amd cores outperforming 16 intel cores. Yey, win!

                But also, I do suspect the "to be rewritten" code is dated and in a need of rework, but facilitating intel's pitiful marketing atrocities is not the right reason and motivation to do it, and will probably swing the design of the new code in a counter-productive direction for the sake of its own interests.
                Last edited by ddriver; 17 February 2024, 12:25 AM.

                Comment


                • #9
                  Originally posted by ddriver View Post

                  Well, if you like performance unpredictability and discrepancy core to core, that's your thing.

                  Usually when people state that they "think" something is a "good" thing, that's followed by some type of elaboration on said "thought process".

                  Cuz the way you currently put it, seems like it is more of a belief than anything else.

                  And let me reassure you, there are ZERO good technical reasons for intel to do that, they just failed time and time again to compete in the core count department. They didn't do that because it is better for the consumer, and in fact did it out of the overly brilliant and technical peak ability of certain people to compare integer numbers to determine which product is "better".

                  And now, as a result of that, we have 8 amd cores outperforming 16 intel cores. Yey, win!

                  But also, I do suspect the "to be rewritten" code is dated and in a need of rework, but facilitating intel's pitiful marketing atrocities is not the right reason and motivation to do it, and will probably swing the design of the new code in a counter-productive direction for the sake of its own interests.
                  I thought the benefits were a given**

                  P cores for perf-per-thread.
                  E cores for perf-per-die.
                  LP cores for perf-per-watt.

                  If you want me to do any more heavy lifting explaining the tech you to you, instead of looking this up yourself, just ask. Scheduling is a solvable problem and just because it's difficult to get good scheduling doesn't mean it isn't worth it once you get it working. Another thing to read about for you is Energy-Aware-Scheduling.

                  ** Intel's implementation of heterogenous chips
                  Last edited by Mitch; 17 February 2024, 12:58 PM. Reason: Clarity

                  Comment


                  • #10
                    Originally posted by Mitch View Post

                    I thought the benefits were a given.

                    P cores for terrible power efficiency
                    E cores for terrible performance
                    LP cores for ... well, lets call simple dma engines "cores" cuz we still don't feel like we propped up our fake numbers enough

                    FTFY. There's a world of a difference between a company that does technical innovation, and a company that's in an abusive monopolistic position frantically trying to mitigate its inability to innovate or compete.

                    ​BTW I was under the impression the "E" stood for "efficient", but looking at real world results, I can't see the E cores solving neither intel's core count disadvantage nor their even worse efficiency disadvantage.

                    If a cpu that is "2/3" "efficient" cores dreadfully losing to a competing cpu with ZERO efficiency cores... that's not a good look, nor evidence of intel being on the right track...


                    I'd encourage intel to make 1 good core and scale it up or down, rather than continue adding more fake cores and needless complexity in the mix. It is not something the tech world needs, it is something intel needs as a substitute for being competitive and competent in their designs.

                    Because keeping on adding n number of core types for each and every way in which your product sucks does not a good product make.

                    It. Only. Makes. It. Worse!

                    Here's a brief on intel's issue:

                    Actual issue:
                    our core is bloated, under-performing and criminally inefficient and we are losing precious enterprise market at a fatal rate

                    Actual solution:
                    get off your hands and fix your bad design, and that's the end of it

                    Non-solution:
                    shove another of your bad cores in there, and continue to bloat your bloated core as your main performance improvement strategy
                    Last edited by ddriver; 17 February 2024, 01:49 AM.

                    Comment

                    Working...
                    X