我在没做过实际测试的情况下论述微内核效率的问题似乎有所不妥，我提出效率的问题也是有机制上的依据的，因为我能在两个问题上提出优化的空间。这两个问题都是基于目前架构最优秀的zircon微内核(我认为)，或是形式化验证过得sel4微内核。
1.微内核进程间通讯效率
短消息机制使微内核利用寄存器实现了进程间短数据的快速传递，这是非常好的机制，非常好的解决了短消息的传递。
不过很明显对于一个微内核来说，一个依赖于进程间数据传递的微内核，仅有快速的短消息很明显是不够的，超过短消息长度之后的数据怎么办？或许可以用直接进行内存映射实现快速且大规模的进程间通讯，资源共享引起的锁的问题怎么办，很明显带有锁应用的设计复杂度较普通应用多得多。或许可以妥善的设计实现无锁，但是很明显使用内核的最广大人民群众并没有普遍具备如此优秀的设计的能力，一边面对丰富多彩的业务逻辑，一边是内核的苛刻要求，开发者简直要怀疑人生的吧。
所以说，微内核已经有了快速的进程间通讯机制，但是面对非常普遍的超过短消息限制的进程间通讯需求，并不足够。我在zircon中看到了应用向块设备写入数据时，不需要将数据复制到文件系统进程再写入，而是直接将待写入数据所在的内存映射了过去，宣称实现了零复制。对于依赖于进程间通讯的微内核，苛刻的零复制明显能够提高数据的读写速度，不过zircon基于capability，要写入VMO的数据需要先形成完整的数据段后再写入VMO，这应该算是一次复制而不是零复制。我有想到真正能够零复制且保障安全的IPC，不出意外地话可以到(3.解决问题)找到。或许这看起来有些极端，但是在用户态的驱动带来的开销下，如何极端、如何丧心病狂的设计都是值得一试的。毕竟，微内核是要与Linux相媲美才能算有所建树，如果同为内核，基本的性能要求都无法与之匹敌，要那些次要的指标何用？
2.微内核响应速度
在微内核的架构中，原本在宏内核中的驱动是活在用户态的进程；也许乍一看没什么问题，就是会产生一些开销；但这开销如何产生，会产生多少？我在<aarch64异常>中说，“写内核的大神们为所有程序猿发福利：这段代码，我们为你们写！(豪迈语气)”。写内核的大神当真是要为全世界发福利吗？
以读写文件为例，当Linux中打开一个文件，要读其中内容时(此处不将对文件的预缓存带来的收益加入考虑)，从read开始，进程飞快的从用户态进程通过系统调用进入了内核态，然后交给worker去搬数据或是直接去搬，有worker搬或许需要等work被调度，以及worker可能还要完成的其他任务，如果直接搬的话则让DMA去做，然后线程可能就暂停切出了，整个过程是非常直接的，worker线程是内核线程，其调度进、出执行都只需要保存现场切换堆栈，毕竟，内核页表是公共的。而在微内核中，还是以我最看好的zircon为例，通过进程通讯，向文件系统进程发出读文件请求；于是作为一个进程的文件系统，进程肯定是逃不开由虚拟地址空间的，有地址空间就要有一套页表，有一套页表就占页表缓存，进程切进切出是开销必然是更大的。而Linux内核中的线程由于共地址空间的优势，worker的开销显然更小一些。
当外部设备产生中断，在Linux中通过中断的处理是在内核中完成，同样由于共地址空间的优势，仅少量的线程切换时间和等待调度时间；而微内核对中断处理的开销则更大一些，进程的切换(含地址空间的切换和线程切换)、等待调度、用户态/内核态转换等均需要开销，需要时间。
用用户态进程实现驱动带来了稳定性，这种稳定性是基于虚拟内存实现的隔离，但虚拟内存的隔离也会带来性能的开销，欲戴其冠必承其重。只有一点性能损失的话，对于现代CPU来说忽略也是可以的，但这使Linux对微内核产生效率(即性能)的优势，一个不能全面压倒Linux的微内核如何应对整个Linux的生态的倾轧。
L4微内核提出了基于capability的权限管理使整个内核都是基于权限搭建，据说实现了安全；我从来对权威的说法都是保持认真聆听的态度，但我从不认为权威既事实；限制对内存的访问，是形成权限的基础，现代计算机体系中通过MMU实现内存访问的限制，如果一段内存如果不是基于MMU来限制访问，那么它无法阻挡躁动不安的指针，而MMU分页最小的单位是4KB；对于基于capability的权限限制，在seL4中内核对象Untyped Memory 最小16bytes，也就是说capability的限制并不是基于MMU设计，于是我猜测seL4微内核不会让用户态的指针真正进入Untyped Memory，而是通过系统调用将其中内容复制出Untyped Memory。在zircon中，对WMO即存在读取和写入其中内容的系统调用，另外将VMO加入一个进程，是需要页对齐的(只有这样才敢允许指针在其中驰骋)。L4微内核基于capability的设计，我能领会其设计意图，但是很明显我才疏学浅，并不能看清基于capability是否能效率、安全兼顾；毕竟本就效率不足的微内核，在与Linux肉搏的时候，再加入更多效率得枷锁，还能否与之匹敌。从zircon来看，capability是与MMU结合了的，并无效率损失，但从sel4上，我并未找到相关线索。
上面啰啰嗦嗦说了我看到了当前阶段微内核还可以改进的地方，其实并不是想表达其设计存在问题，而是说，我有想到实现一些更好的机制可以提升上述两个问题
