长期的Linux内核开发人员Thomas Gleixner在Intel旗下的Linuconix工作了几个月，在过去的几个月里一直在重新编写Linux内核的x86CPU拓扑评估代码。这是为了清理一堆陈旧的内核代码，以及在当今混合英特尔酷睿处理器时代代码的某些方面是不正确的，其中混合了P/E内核和缺乏SMT/HT的E内核，从而抛弃了先前的内核假设。随着代码现在排在TIP分支中，看起来CPU拓扑返工可以很好地应用于Linux6.9。
自去年夏天以来，Gleixner一直致力于改进Linux内核中的x86CPU拓扑学评估代码。与很久以前开始的许多内核代码一样，随着时间的推移，它已经变得毛骨悚然，而且考虑到今天的英特尔酷睿混合处理器设计，它有错误的假设。Gleixner去年夏天在他的补丁附函原件：
“最近提交的CPUID叶0xb/0x1f解析器让我更深入地研究了拓扑是如何计算的。那个”修复“只是完全忽略潜在灾难的sypmtom hack的又一次治愈。
拓扑计算的工作方式是尽可能频繁地覆盖相关变量。例如，smp_num_siblings被覆盖了无数次，这是错误的。引导CPU写入它3次，每个AP两次。
更糟糕的是，这只是偶然在混合系统上工作，因为现有的系统似乎都是在具有SMT的P-Core上启动的。如果它在没有SMT的E-Core上启动，那么早期的拓扑评估的部分将是完全错误的，包括并行CPU启动所需的主线程掩码。以后用正确的值覆盖它根本无济于事。
如今，混合引擎的问题已经出在每个封装的内核数量上。在具有8个P-核和8个E-核的ADL上，每个包的最终核心数被评估为12。这并不奇怪，因为CPUID 0xb/0x1f解析器查看核心级别的逻辑处理器的数量，并将它们除以SMP兄弟的数量。
24/2=12
只是这款CPU显然有16个核心，而不是12个。
它甚至在SDM中清楚地记录了这是错误的。
..。
这种“不用于拓扑评估”的句子甚至在杂交体出现之前就已经存在了，但被忽视了。这个代码碰巧起作用了，但对于混合动力车来说，所有的赌注都是错的。一旦CPUID叶0x1f列举了core和die之间的任何拓扑级，代码就完全崩溃了，但这并不令人惊讶。正确的做法是根据固件提供的APICID和适当的拓扑域级别解析器实际评估完整的拓扑，包括不存在的(热插拔)CPU。这甚至可以在引导单个AP之前准确地告知物理包、逻辑包等的数量。所有这些都可以预先评估。
除此之外，有太多的地方进行自己的拓扑评估，但绝对没有中心点可以真正以一致的方式提供所有这些信息。这种情况需要改变。
在过去的半年里，这个改进Intel/AMD/Hygon/Centaur/Zhaoxin CPU拓扑评估代码的大补丁系列已经修订了六次。
现在它的状况很好，许多补丁在里面排队Tip/tip.git的x86/APIC分支. With it making its way to a TIP branch, it's likely to be submitted for next month's Linux 6.9 merge window unless any new issues come to light or objections raised by Linus Torvalds.
