本文由知名博主Dog250投稿Linux阅码场原创发表。
《有关微内核OS史上最透彻一篇 - 写于华为鸿蒙发布一周之际》
剪辑自腾讯云安全
情景分析。
我就以普通的读取文件的read调用,以Minix为例,展现一下其行为:服务器
这里须要解释的是,上述情景的每个步骤看样子都在进行进程间通讯(IPC)。确实,这就是微内核的特点之所在。网络
为了让系统核心的服务进程好比FS,MM更好的对每个用户进程服务,在这些进程内部,均保存着系统全部进程的当前与本服务进程相关信息的快照。数据结构
FS进程请求SYS进程将从磁盘读取的内容复制到用户进程P的缓冲区,这一步是没有用户进程参与的,因此FS进程至少要知道用户进程P的内存信息元数据,这样才可让内核态的SYS进程完成复制操做。
其实,能够这样理解,在微内核中,FS,MM这些服务进程的逻辑以及快照数据在宏内核中就是对应内核自己的,只不过它们的访问方式不一样:架构
做为对比,咱们看一下宏内核Linux是如何完成与上面的情景IPC等价的操做步骤的:并发
看样子一样是read读取文件,微内核只是把宏内核的纵向通讯换成了横向通讯而已。然而这个一纵一横的背后,却隐藏着大不一样。app
对照OSI以及TCP/IP分层模型,以上的说辞便再熟悉不过了。socket
若是只是为介绍微内核的运行原理和流程,我想到这里已经结束了,下面该能够愉快地看代码了。然而微内核在现实中并不是能够和宏内核分庭抗礼,咱们不使用它,不接受它,除了商业和生态因素致使的先入为主以外,还有一个更加剧要的因素,即 性能。模块化
微内核性能太差了! 全部人都认为微内核性能差是由于IPC开销大,系统调用开销大所致使。固然,我也是这么认为。可是这只是事情的一面,事情还有另外一面。函数
关于微内核的话题,无外乎就是:
好多话题网上一搜一箩筐,大多数都是形而上的套话,也不想在这里再次复制粘贴。
接下来我仅仅针对 性能 方面来对微内核进行一个定性的评估。另外,我尝试为微内核的性能表现作一番洗白。
一说到对等层的逻辑通讯,最终仍是要落实到纵向的物理通讯来落地,仍然以我比较熟悉的网络方面来类比。典型的TCP/IP的通讯模型以下:
对于Minix微内核的read场景,和TCP/IP的模型几乎一致,在横向对等IPC之下,真正落地的是纵向通讯。对应上述IPC横向逻辑通讯过程的纵向实际流程以下图所示:
只要稍微一看这个图,第一个个感受就是 这太TM繁琐了! 宏内核一个系统调用的事,微内核的IPC居然要12个系统调用,并且仅仅是send/receive重复6对!如此设计性能显然好不了,意义何在呢?这个后面会讲。
对于微内核而言,只须要send,receive两个系统调用就够了,全部的系统功能均可以经过send/receive两个系统调用封装IPC消息来完成。
对应的,相似FS,MM这样的服务进程,就像普通的Web服务器守护进程那样,在一个大循环里等待receive就行了。
极简主义的典范,不是吗?这让咱们能够联想到RISC处理器,看它们的汇编指令时,访存寻址只有load/store两个指令,也是极简主义的典范。
极简归极简,可是请看看上面那繁琐的流程,在宏内核中一个read系统调用的事,在Minix微内核中居然要整整12个系统调用才能完成。回到上面的话题, 性能何在?效率何在?意义何在?
这是微内核饱受诟病的核心。
确实,纯传统IPC的方案,如此多的系统调用,开销是很是可观的。然而,经过以太网的发展史,咱们或许能够看到曙光。
咱们看看早期的共享总线式以太网:
[注]工做方式:CSMA/CD(载波监听多路访问/冲突检测)先听后发,边听边发,冲突中止,随机延迟重发
。
咱们对比一下宏内核:
也许是咱们对宏内核太熟悉了,咱们每天都在用Linux内核,不是吗?这致使咱们可能看不到别的可能性,这个事实将咱们蒙蔽在真相之下,使咱们看不到宏内核实际上是有很大问题的,好比多核的不可扩展性。【固然,Linux内核在多核扩展性方面一致在持续优化,这无可厚非,可是始终没有一个让人哇塞的方案...】
宏内核缺少访问共享资源的有序仲裁机制,所以同步开销会很是大,最直接的后果就是宏内核随着处理器核心的增长而不可扩展。这个现状和早期以太网是多么类似, “以太网随着共享总线上接入的计算机数量的增长而性能陡降”。
全部使用内核服务的进程都在各自 隔离的上下文(现代操做系统之因此现代的缘由) 中访问底层的共享资源,这是没法仲裁的根源。
说回以太网,当事情发展到交换式以太网的时候,问题解决了,由于冲突域坍缩到了交换机的背板总线,做为具有二层逻辑处理能力的交换机,它即可以进行必要的资源仲裁,好比排队以及队列的调度,实现数据包的存储转发:
数据包的有序排队代替了对总线的无序争抢,从而避免了冲突。
让咱们看看微内核,与此是多么类似:
咱们回看并思考一下以太网进化到交换式以太网时的情形。
面对交换式以太网,有人确定会质疑, 原来数据包能够直接经过一根线飞到目的地,如今还要去交换机里走一遭,还有经由交换机逻辑的处理,多了这么多的步骤,如何能和曾经共享总线时一根线相比呢?
质疑者明显是忽略了CSMA/CD的开销。相比CSMA/CD的开销,交换机的处理开销与之作减法,最终化做了收益。【交换式以太网今后飞起,现在万兆以太网都已是标配了】
类比以太网的发展历史,若是咱们考虑多核处理器上宏内核的无序同步开销,在微内核中加入带有仲裁功能的服务进程后居然大大下降甚至消失了,是否是有一丝的欣慰呢?
有了交换机以后,人们忘记了CSMA/CD(虽然仍是要考试),那么若干年后,是否是也能忘掉spinlock【冲突原地等待】呢?
其实,在咱们使用宏内核时也不是不明白专门进程处理专门事情的重要性,只是这种感受来得比较自发罢了,并无造成书面上的方法论。典型的例子就是最近几年很是风靡的Linux用户态协议栈。
为何要构建用户态协议栈【权限-内核资源空间-并发】,那明显是由于内核协议栈性能低。用户态协议栈能够作到专核专用,进程上下文能够彻底掌握数据包收包逻辑的全过程,更便于仲裁和协做。
若是用户态协议栈抽象成一个服务,这是否是就和微内核思想一致呢?
此外,除了协议栈,不少别的逻辑也纷纷往用户态搬迁,而且,在内核态自己,中断也愈来愈线程化了,以便统一参与内核的调度。微内核的思想一直在背后起着做用。
原本微内核的性能是软肋,结果被我说的好像成了它的优点,有点不太雅。但其实,我表达的更多的是微内核表现出来的一种潜力。站在多核心可扩展性角度,多核平台,无疑微内核的设计会更好,服务进程的仲裁可让应用在多核平台无锁运行。
不过不管如何,我认可性能确实是微内核的软肋,特别是Minix的性能确实不咋地,但这也一样意味着微内核能够针对性能这个软肋集中地进行优化。业界公认的性能比较好的微内核当属QNX了,它被普遍部署在黑莓手机和汽车上,时间和存在能够证实,它守住了它承诺的。
在UNIX历史的长河中,一开始的系统就是奔着微内核的思想去的,好比最初的UNIX系统中会拥有一个专门负责调度和交换的swapper进程,直到如今,咱们依然能够在UNIX/Linux中找到一个0号的swapper/idle进程,虽然它早就被淹没在宏内核之中,不再行调度以及交换之事务了。
说到微内核的性能问题,我认为在通过了30多年的发展后,微内核,宏内核之间的性能差距已经大大缩小了,这个关于两种因为设计理念的不一样致使的性能差别话题在计算机的发展史上,历来就没有中止过:
可是无一例外,最终谁也吊打不了谁,收益必有代价,大多数的纷争最终走向了融合。
硬件技术的发展每每落后于软件技术的发展,可是硬件技术倒是始终不断发展的,在此期间,软件技术每每陷入了两种理念的纷争而稍有停滞,最终硬件技术跟上,弥补软件性能的缺陷。甚至硬件能够针对软件的需求做出特殊的支持。
软件提出需求,硬件实现。若是微内核在理论上证实确实好,仅仅IPC是个瓶颈的话,直接从硬件上着手优化,岂不是更好吗?我想QNX,鸿蒙的设计应该也是这么考虑的吧。
软件硬件统一支持,我想微内核和宏内核之间最终也会是某种融合,我说的并不是Windows做为混合内核的那种马赛克式的融合,而是熔炉式的融合。
具体到微内核性能差的根因,咱们来聊一下IPC的优化。
若是实现一个最基本最简单的IPC,那么内存拷贝就够了。这通常是0.1到1.0的作法。先让系统跑起来是最重要的, 完成比完美更重要 。【GNU Hurd内核的失败就是由于斯托曼太过理想主义,追求完美...反例则是李纳斯,追求完成。】
随着硬件技术的发展,随着系统对性能要求不断提升,IPC必然要不断优化,内存拷贝再也不适用,共享内存则更好,最终,可能直接使用硬件的某种机制,好比寄存器,DMA等机制来帮助实现IPC。若是有硬件机制直接提供IPC的支持,问题就解决了。
这个过程很是相似sendfile/splice系统调用的设计过程。
sendfile/splice的设计
____起初,Web服务器须要先将文件拷贝到Web服务器内部buffer,而后再将buffer拷贝到用户的socket。这很相似传统的IPC方案。
____然而随着HTTP逐渐主宰互联网,几乎每个Linux服务器上均部署有Web服务器,谁还能忍受两次拷贝的瓶颈,因而sendfile就呼之欲出了。sendfile仅仅提供一个外部把手,真正的数据并不须要拷贝到Web服务器的buffer,经过这个把手,数据能够从文件直通到socket。
____用的人多了,需求在了,问题天然也就解决了,并且是从底层根本上解决。微内核的IPC也会是这样的路子。
不过,目前尚未一个通用的使用在微内核上的IPC机制,相信QNX是有优化过的IPC的,可是不够通用,而Android系统的Binder够通用也还不错,可是它并不针对微内核。却是很是但愿能看看鸿蒙是怎么去优化的。
最后,我想说点儿有意思可是你们不怎么关注的东西。
文章终于写完了, 原本想就此结束的,但仍是想说点内心话。
最开头说了,但愿能经过本文里的东西给你们带来点 技术 ,也确实,我专门为此在文中加入了源码分析。但愿真的是把技术讲明白了,但毕竟这仅仅只是一篇文章,因此也就不能面面俱到,但即使是如此,我也但愿本文至少能够做为关于微内核的科普,也就倍感欣慰了。
本文以鸿蒙操做系统做为引子,但也只是引子,我没见过鸿蒙系统真正的样子,因此我也不去过多猜想,没见过的东西,也没参与,过后去指点江山,总以为缺了点什么。鸿蒙一出,发现网上瞬间出现这么多精通操做系统设计和开发的专家,原来你们之前真的都是潜龙勿用啊,现在变身,飞龙在天了。
也真是替华为感到遗憾,当年招聘的时候,有这么多专家都化名为鲲,潜在北冥不该召,现在一张PPT就让他们集体化而为鸟,怒而飞,更名为鹏了...
操做系统这门学科在即便计算机专业内部也并不算大众,由于它太底层,而且太复杂太无趣了,偏学术,让人以为老套。没有漂亮产品妹子蹦蹦哒哒过来跟你对需求,也没什么班可加,完过后你们一块儿去啤酒撸串,更多的时候是你本身一我的大半夜在家里debug或者思考。
很难出成绩,这意味着加薪周期会比较长。
动辄以两年为单位的研发周期长,不符合BAT等大型互联网公司一年两次考核的快速迭代小步快跑理念,这意味着你可能连本身的工做都保不住。
多年不变的夯实的架构让操做系统领域显然没有更多新的东西可作,这就像TCP/IP协议栈同样,千年不变的底层架构显然让你的职业生涯并无多少机会去拥抱变化,这显然和互联网理念是背道而驰的。
说白了,不少人对此并不感兴趣。
鸿蒙发布以后,忽然发现不少人都是操做系统专家了,我想这是在蹭华为的热度而不是鸿蒙操做系统自己吧,由于操做系统自Windows 95,Windows XP以后,历来都没有再热过。不信你回家问问本身的家人,除了Windows 95/XP以外,还据说过哪一个划时代的操做系统。
最后,想喷我站队华为的,先给在下演示一下如何在鸿蒙操做系统上写hello world再说吧,反正我没见过,等我看见了,若是它真的不如人所愿,我和你一块儿喷。打架不会,喷人仍是有一套的。