字节跳动为Linux提出“Parker”方案：实现多内核并行运行
就在数日前，有人为Linux内核提出了多内核架构方案。与Multikernel Technologies的提案不同，字节跳动其实一直在研发名为Parker的类似方案。今日字节跳动正式揭晓Parker——这是其在同一硬件/系统上实现多内核并行运行的解决方案。
字节跳动的Parker可在单台机器上同时运行多个Linux内核，无需依赖KVM等虚拟化技术。Parker通过对CPU核心、内存及设备进行分区，构建出具备分区感知能力的Linux内核。字节跳动在提案中承认，该方案在某些方面与近期提出的Multikernel RFC相似，但设计和实现完全不同。
今日Parker公告进一步阐述了其多内核设计方案：
“每个内核实例可使用相同镜像，但初始内核(即引导内核)负责控制硬件分配与分区。其余内核均为次级内核(应用内核)，各自管理其分配的CPU/内存/I/O设备。”
Parker的主要应用场景是高核心数机器，这类环境可能存在可扩展性问题。启动后，内核实例之间不存在通信。换言之，它们不共享任何资源，从而提升可扩展性。每个内核都需要独立的(PCIe)设备进行I/O操作，例如NVMe或网卡。另一种可能的应用场景是：根据工作负载需求，为不同内核实例配置差异化的性能调优方案、CONFIG_选项以及FDO/PGO策略。
目前多家企业正致力于多内核实验，以更好地应对当代高核心数系统。这项工作将走向何方，以及其中哪些方案最终能演进为适用于上游Linux内核的设计，值得持续关注。
> 每个内核实例可以使用相同的映像，但初始内核(即引导内核)负责控制硬件分配和分区
这看起来合理得多。我们拭目以待后续发展。
我认为这是大胆举措，未来或可实现无停机内核升级。想象逐个核心升级内核版本的情景。
若无特殊集成(无资源共享)，相较现有虚拟机监控程序有何优势？
个人认为他们操作层级有误。让UEFI处理分区不是更合理吗？
这听起来像是升级地狱：既要升级基础内核(可能导致所有次级内核重启)，还要升级所有次级内核。
若服务器主板通过IPMI/BMC支持处理分区与资源分配(内存、PCIe、核心，甚至映射到VLAN的虚拟网卡)，就相当于将多台服务器整合于单个机箱中。
为何不能用cgroups实现分区？这似乎是为达成相同目标增加额外步骤。
运行多个虚拟机→运行多个操作系统→运行多个容器→运行多个内核→为每个进程运行多个snap包——这一切都极其必要。
只盼内核工程师能专注添加更多导致臃肿的抽象层。越多越好！
这是脑腐症的反噬。
针对不同后端Python 2/3虚拟化/打包方案的专用snap包：
-pip -pipx -pipenv -pipsi -pip-run -poetry -fades -pae -pactivate -virtualenv -pyenv -pdm -pypi -egg -wheel -setuptools
拼写错误：comletely
这根本无法解决问题。更新根内核仍需依赖那些超级黑客级的内核切换技术，或采用传统的重启方式。
我理解现代服务器体积庞大且密度高，需要拆分成小型服务器，但KVM虚拟化技术早已能以更灵活的方式实现这些功能，同时具备更优的隔离性、卓越性能和低开销。它还能通过USB和PCIe直通技术达成相同效果，且多数情况下无需强制执行。
但这种方案真正失败之处在于：这类架构真的需要不同内核吗？例如：如果根内核是el10内核，而这台超大规模服务器正处理数十亿条社交媒体数据请求，为何还要使用根内核之外的不同内核？难道不能仅通过同一内核的不同配置来实现吗？运行不同版本内核或打不同补丁的内核，无异于自找麻烦。
我更倾向于相反的SSI(单一系统映像)理念——让单一内核跨多台机器运行。就像Kerrighed那样。
汉斯·赖泽(没错，就是那个因ReiserFS臭名昭著的家伙)曾撰文探讨过类似方法实现Linux内核可扩展性。他提议在独立的NUMA节点上运行独立内核(甚至可能在通过网络连接的物理节点上运行)。有人能找到那篇文章吗？
采用此方案的原因在于虚拟机监控程序确实存在开销。
Parker 在其 lkml 条目中明确指出，这并非虚拟机监控程序的替代方案。
这正是问题的症结所在。运行在同一内核上的cgroups/容器最终可能因争夺相同内核锁而发生冲突。
我们确实需要多种方式启动多个内核实例。假设尝试扩展cgroups以对抗帕克方案——通过实例间的内核锁分离实现隔离——很快就会引入大量检查机制，这些操作都会消耗性能。
虚拟机监控程序方案同样存在类似问题：调用监控程序的开销不可忽视，虽然它提供了额外安全性，但这种安全性并非免费获得。
这些方案应定位在cgroup/容器与虚拟机之间的中间地带：比cgroup/容器提供更强的锁隔离性，比虚拟机更优的性能，同时具备cgroup/容器级别的安全性。确实有时性能会略逊于cgroup/容器。正如前文所述，这些方案将介于cgroup/容器与虚拟机之间。在某些特定场景下，虚拟机和cgroup容器都难以完美适配，这正是目前两类方案并存的原因。
如果cgroup在几周后进入内核，随后又出现2到3个新功能，那么林纳斯就必须强硬表态，要求各方坐下来整理好各自的解决方案。
实时补丁不是早已存在吗？
说真的，我们能不能先解决可扩展性问题？如果插槽密度已经这么高了，那就别再买更高密度的插槽了。
嘿兄弟，听说你喜欢跑内核？这就给你个内核来启动另一个内核，再运行一个内核来运行内核。
我打算配置系统同时运行三个内核，这样它们就能互相验证是否有人搞鬼。我预见不到任何问题。
汉斯·赖泽(没错，就是那个因ReiserFS臭名昭著的家伙)曾用类似方法撰写过一篇关于Linux内核可扩展性的文章。他提议在独立的NUMA节点上运行独立内核(我认为甚至可能在通过网络连接的独立物理节点上运行)。有人能找到那篇文章吗？
这听起来简直愚蠢，内核正是连接硬件与应用程序的中枢。应用程序才是通过互联网通信并构建集群的主体。
至于不同NUMA节点？我认为Linux自Reiser时代已取得长足进步，完全能够在NUMA系统上高效运行，根本无需在每个节点单独运行内核……
过去将单一存储设备划分为C:和D:被视为资源浪费。十余年后，这种方法被公认为更高效利用存储空间的手段。
如今，将CPU核心分割为多个独立“迷你CPU”，使多个内核(或操作系统——若发展方向如我所料)能在裸机上原生运行的构想，反而被视为荒谬。谁知道呢，或许十年后这将成为人人习以为常的事。
企业与科技巨头投入如此庞大的研发资源和资金，必然是出于某种利益考量。而两家企业提出相同方案的情况更是凤毛麟角。
我原以为_Parker_是指《雷霆鸟》中佩内洛普夫人的司机，结果竟是分区内核。
我以为IBM在大型机上(逻辑分区LPAR)搞这套技术已有数十年历史？
记得IBM将PC业务卖给联想时，我曾买过一台打折的M系列x86主机，惊讶地发现其固件里竟内置了虚拟机监控程序。当时觉得奇怪，现在想来其实合情合理。
我不确定初始或启动内核是否需要完整Linux内核——它只需实现资源管理，且不同于虚拟机系统无需虚拟化设备 (所有设备均可采用直通模式)。策略管理可由专用操作系统分区负责。
现有微内核或许更适合作为初始内核。
是的，EFI正是实现此功能的正确层级。英特尔早在2005年就实现了这项技术，当时称为“para-partitioning”，能够启动两个不同的Linux实例，并将所有PCIe设备分配给其中一个实例。不过当时仅支持两个实例。
我并非评价这项技术优劣，但信任UEFI厂商似乎并非明智之举。毕竟UEFI并非统一标准，即便存在标准，众多厂商也并未遵循。既然存在统一的软件解决方案(理论上)能满足所有需求，为何还要将信任交给每个UEFI供应商？
确实存在，但似乎并非适用于所有场景。据我所知，根据更新对象的不同，某些情况下仍需重启系统。虽然替换整个内核很理想，但我仍担心在执行此操作前将进程从一个内核迁移到另一个内核的问题。
反正你终究得信任主板(及其UEFI实现方案)。
多年前我在凯维姆工作时，我们曾尝试过这种方案。当时有位客户的软件存在组件差异：部分组件采用小端模式，而网络处理代码却使用大端模式。通过对U-Boot进行改造并稍作Linux内核调整，我们实现了两个Linux内核在不同MIPS核心上并行运行——一个内核运行于小端模式，另一个运行于大端模式，两者通过特殊网络环回接口连接。虽然方案可行，但我们从未深入推进，最终放弃了该方案。当时Cavium采用的是“简单执行程序”架构：专用核心运行裸机应用程序，其他专用核心运行Linux内核，内存由U-Boot进行分区管理。如今已有更优雅的解决方案——通过任务隔离实现数据包处理。若当初能继续推进这个方案，应该会很有趣，毕竟我们已经验证过其可行性。
我既信任又怀疑。信任——因为别无选择；怀疑——因为不同UEFI实现导致诸多问题。
我理解他们试图减少通过虚拟机监控程序进行I/O操作的开销，但不禁思考是否存在更优的实现方式。
例如，io_uring 通过基本完全避免系统调用，巧妙地绕开了系统调用开销的问题。类似的方法是否也能用于解决许多虚拟机监控程序的开销问题呢？