0作为我当前研究的一部分，我一直在进行测试，通过回显或模拟垂直缩放1来禁用/重新启用核心 。/sys/devices/system/cpu/cpuN/online
使用内核 v4.4.0（Ubuntu 16.04 LTS），这在多台 Xeon E3 机器上完美运行。最近，我有机会测试双插槽 EPYC 7281 机器，同样在 Ubuntu 16.04 上使用 v4.4.0。禁用这些系统上的核心工作正常。然而，当重新启用它们时，它们被 lscpu 和 htop 显示为在线，但直到我重新启动机器，它们才再次被安排工作，即当我对机器进行压力测试时，htop 显示只有之前未被禁用和重新启用的核心正在使用。
换句话说：在 Xeon 机器上，我首先禁用除核心 #0 之外的所有核心，然后再次重新启用它们。之后，一切都像禁用核心之前一样正常运行。在 EPYC 机器上，即使在重新启用它们之后，即使 htop 和 lscpu 显示它们可用，已禁用的内核也不会再次使用。
我无法再访问 EPYC 机器来进一步测试（只使用了 2 周，并且不允许升级到更新的内核），但我们正在考虑购买新硬件，我需要查明 Threadripper/ EPYC（一般为 Zen）通常无法通过内核禁用/重新启用内核，或者这是否只是一些奇怪的孤立问题。
我的问题是：
核心无法正常上线可能是旧版 4.4 的问题吗？内核，那么如果我升级到较新的内核，这个问题会得到解决吗？不幸的是，我无法测试这一点，因为我无法再访问 EPYC 机器（否则，这篇文章不会在这里:)）。然而，我可以完全控制我们的新硬件。因此，如果新内核解决了这个问题，我会很高兴。
如果不是由于内核版本的原因，为什么 EPYC 会以这种方式运行，我可以采取什么措施来解决这个问题？
我尝试寻找答案，但到目前为止还没有找到任何结论性的东西，除了自内核 v4.10 及更高版本以来显然已经有很多基于 Zen 的 CPU 的补丁这一事实。
我在看这个链接，其中提供了有关该过程如何在 Intel CPU 上工作的一些详细信息，甚至还链接到负责禁用内核的实际代码。不幸的是，这并没有多大帮助，至少我没有足够理解来回答我的问题。
这也没有帮助，因为我需要在运行时垂直缩放核心，而无需重新启动。
我还在较新的内核中发现了一些对新电源管理系统的引用，但这超出了我的理解范围：-/
或者，如果当前拥有带有最新内核的 Threadripper 或 EPYC 系统的任何人都可以通过禁用/重新启用内核然后加载它们来检查来运行快速测试，那么也许不需要挖掘和找到问题的根源，就足够了它们是否被正确利用？
我真的很感激任何关于这个问题的见解和帮助！
如果有必要，我会在这里提供更多详细信息，我不知道还需要什么来解释这种行为。另外，这是问这个问题的正确交流方式吗？或者您会推荐任何其他寻求帮助的方式吗？
答案1
好吧，为了后代，我已经通过实验找到了答案。
我的一位同事在内核 v4.15 的满载 EPYC 7281 机器上进行了快速测试，方法是禁用 31/32 核心并再次重新启用它们。所有禁用的核心都再次被正确利用，因此我之前遇到的问题似乎已经消失。
目前尚不清楚哪个版本包含此修复程序，也不清楚是否存在任何其他可能影响此结果的其他变化因素，但目前我相当确定，拥有较新的内核可以让人们在基于 Zen 的 CPU 上禁用/启用内核而不会出现问题。