鸿蒙内核超越Linux内核？如何看待

linux

鸿蒙内核为微内核架构（更多创新可于7月公开的osdi论文查看），可仍有很多诸如是否基于linux、是否套壳、含多少linux代码、不开源是否违反GPL之类的评论。本想不理会，但有人会问为何不回应，是不是不敢？其实只要认真读下论文摘要，就不会有这种多余的疑问了。这里有必要再次澄清一下：鸿蒙内核是由陈海波老师带领华为内核实验室的数百人，历经多年从零开发而成的。它是一个基于微内核架构、已经全面商用（像tee、部分管道设备、车等方面）的通用操作系统内核。这个内核涵盖了包括调度、内存管理、文件系统、中断、信号、进程管理等所有你知道的内核核心组件，并且是全部重新设计与实现的。鸿蒙内核旨在以API、ABI兼容的方式，承接数以千计无需修改的北向应用生态；以用户态进程级Driver ContAIner方式，承接仅需极少量适配的南向linux驱动生态。在用户态LDC里存在linux驱动代码，遵循GPL协议，不过仅限于慢速设备。像UFS、GPU等需要性能或者特权级支持的设备，也都全面基于鸿蒙内核Native DC接口进行了重写，而且Native DC和LDC之间有地址空间隔离。顺便说一句，如果将来有人愿意基于鸿蒙内核Native DC接口重写这些慢速设备驱动代码（闭源的无法操作），那么这种情况下的鸿蒙内核就可以说不包含任何一行linux代码了。鸿蒙内核采用南北向兼容设计，能支持linux的大多数场景，像嵌入式、终端（手机、平板、PC）、智能车，甚至计算、云等场景也可支持。目前支持的包括AOSP、鸿蒙Next等（便于性能基线对比）。不过，因鸿蒙自身设计，在嵌入式、终端、车等少核且对可扩展性要求不高的场景下，鸿蒙较linux有显著优势。在众核计算场景，由于尚无项目支撑，没有需求就缺乏相应设计，和linux相比存在不小差距。论文尚未公开，只能在ABStract板块澄清。工作量大，只能趁午饭时间澄清。我很少看评论区，诸位不必再于评论区不停展示逻辑思维了。若对鸿蒙内核感兴趣，且想加入我们一起干一番大事业的同学，欢迎联系我们。我们可多地入职，包括北京、上海、南京、深圳、杭州、德累斯顿、莫斯科、渥太华等地。

我全程参与鸿蒙内核开发，在不违反信息安全的情况下，简单说几点。单纯对比两个内核的微观性能没太大意义。即便加上定语从流畅度来看，虽说增加了一定的可比空间，但要是测试用例不明确，那就只能定性分析，不太会有一方碾压或超越另一方的情况。即便测试用例明确了，像业界用于测试性能的lmbench、geekbench这类benchmark，也是各有胜负，很少会出现单方面获胜的情况。举个简单例子，通常宏核的所有内核对象状态是统一集中管理的，而微内核由于服务地址空间隔离，很多状态分散在各个组件。仅考察fork这个语义，微内核无论如何也达不到宏核的水平，这也是众多微内核不支持fork的原因，更别提微核IPC的传统性能瓶颈了。所以在学术界，正常比较两个系统或者子系统时，首先会固定变量，然后得出类似下面的对比数据：

可参考atc18 - bouron.pdf (usenix.org)的比较两个调度器的方式，不过这种比较通常很难判定谁优谁劣。要是有同学对鸿蒙内核和linux的细节以及benchmark（基准测试）对比感兴趣的话，不妨等等Microkernel Goes General: Performance and Compatibility in the HongMeng Production Microkernel | USENIX这篇文章，它7月就会公开了。但多数microbench领先，就能表明内核超越了吗？答案显然是否定的。系统的终极目标是用户体验，而用户体验是个复杂的系统工程，我们切不可陷入不服跑个分的误区，要认清跑分没赢过，体验没输过背后的逻辑。linux是全球众多优秀程序员数十年合作的成果，不过它并非是普适且万能的。强调这点是为了让大家明白一个概念：软件，乃至世界上任何抽象事物（包括政治制度），并没有绝对的优劣之分，只有是否合适。开源软件的发展如同茁壮成长的树苗，其成长方向是由大家给予的需求所决定的。linux作为通用服务器领域的基石，长期被Intel、Red Hat掌控，始终朝着服务器操作系统方向发展。一个小小的8核、16核桌面系统或者小型终端设备，真的需要复杂的NUMA balance算法吗？为了可扩展性，有必要将任何一个内核对象设计得极为复杂吗？需要耗费高昂的底层资源去做很多针对特定场景的事吗？这就是当年CK提出疑问的原因：既然linux能很好地支持4096核，可为什么我播放flah时还会卡顿？

华为

还有一个极为严重的问题，linux堪称分层解耦的范例，能用于支持世界上的绝大多数设备，可它居然没有完善的QoS软硬抽象（垂直整合）。这其实不难理解，因为服务器上运行的都是大型应用，只要在运行就都是重要且合理的任务。然而这种设计，在云混部场景以及终端场景下，却犹如一场灾难。我在2019年的OS2ATC上有一个话题，介绍了linux调度器存在哪些问题，以及我们为何如此重视QoS。有兴趣的人可以看这里：OS2ATC：操作系统调度器的演进_23628.pdf (debian.cn)linux也在朝着一些定制化场景努力，像谷歌、Meta这些新玩家就在推动。要是感兴趣的话，可以看看sched_ext的上游流程。只能说这个过程充满坎坷，道路艰难，其间还存在不少利益争斗。sched: 实现BPF可扩展调度器类。于是，我们能对鸿蒙内核已经超越linux内核这一表述加以改进。可以这样讲，鸿蒙内核是一种更契合终端通用场景的操作系统内核。在那些要求确定性低时延（搞linux的人应该都清楚，linux的rt patch历经十来年还未能全部upstream，可查看realtime:documentation:start (linuxfoundation.org)）、需要顾及续航以及极低功耗的用户场景中，鸿蒙内核的工作表现更佳，也更为适用（例如其调度底噪仅为linux的25% - 50%）。要是直接把鸿蒙内核应用于计算领域，就当前的代码状况而言，其表现恐怕也是不太理想的。3、有人说linux是开源的，于是就问，那它会不会被卡脖子？这是不是在重复造轮子？鸿蒙内核的开发者，好多都有着长达十来年的linux开发经验。要是简单裁剪、拉分支就能解决问题的话，也就没必要自研内核了。linux存在低内聚、高耦合的情况，像调度、内存管理这些传统内核组件，根本没办法单独替换，更谈不上实时替换了，这样的弹性难以适应未来多变的场景和硬件形态。宏核架构一直被安全性问题所困扰。还有不少人觉得开源就是无国界、无垄断的，好像世界大同一样，这其实是只知其一不知其二，要知道有人的地方就有纷争。为啥Arm想合并big.LTTLE的EAS代码得花五六年的功夫？为啥费了好大精力搞出的schedfreq说被schedutil取代就取代了？为啥Google要在主线之外另起炉灶维护一个分支，回归主线都说了多少次了？为啥有开发者宣称以后再也不审核俄罗斯开发者提交的代码了？哎，都懒得细说了。 以上。