我在沒做過實際測試的情況下論述微內核效率的問題似乎有所不妥，我提出效率的問題也是有機制上的依據的，因爲我能在兩個問題上提出優化的空間。這兩個問題都是基於目前架構最優秀的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上，我並未找到相關線索。
上面囉囉嗦嗦說了我看到了當前階段微內核還可以改進的地方，其實並不是想表達其設計存在問題，而是說，我有想到實現一些更好的機制可以提升上述兩個問題