原文表5指（图1），原文图11指（图2）
6.2 性能
我们展示了HM和Linux在新兴场景中的端到端性能比较，包括智能手机（使用Kirin9000 SoC）、智能车辆和智能路由器，这些场景现有的微内核无法支持。所比较的Linux 5.10对应版本已经高度优化（在以前产品中使用），而不是原始版本。
···LMbench。我们在Kirin9000上使用LMbench评估基本操作系统功能。表5（图1）显示了与操作系统架构相关的结果。与Linux（5.10）相比，HM的上下文切换lat_ctx（32%）和网络（平均21%）更快，主要是由于与Linux相比处理程序更简单。内存操作与Linux表现相似。尽管fork在微基准测试中仍然比Linux差，我们观察到fork在现实负载中的主要开销来自复制虚拟内存区域（VMAs）。通过并行性可以加速它，将其开销从150ms减少到60ms（在典型应用程序中，接近Linux中的30ms）。Clone（创建线程）也比Linux慢1倍，主要是由于多个操作系统服务（特别是IC2中的驱动程序容器）和核心内核之间的额外IPC。
···Geekbench。图11c展示了CPU密集型Geekbench 5.3.2的单核结果的归一化。通过优先考虑性能的系统组装，HM实现了与Linux类似的性能，由于不同的CPU频率调整策略，只有微小的差异。
···应用程序冷启动时间。应用程序启动时间对用户体验至关重要，它强调了多个操作系统服务（例如，从闪存读取和创建线程）以及大量的IPC。图11a显示了HM上排名前30的AOSP应用程序的启动时间。Linux和HM上的框架/应用程序版本相同。正如第3.1节所分析的，微内核在这种情况下的主要开销来自状态双重记账和慢分页，这是HM消除的。因此，启动时间甚至比Linux短17%（几何平均值），主要是由于更轻的负载（见下文）和自定义调度策略。
···应用程序负载。图11b显示了不同场景下一段时间内的负载。负载（执行指令的数量）是使用perf收集的，包括操作系统服务中的执行指令（或在Linux内核中）。HM的负载比Linux轻19%（几何平均值）。HM提出的技术显著减少了最小化和细粒度访问控制的开销。更轻的负载也使HM能够实现比Linux更好的性能和能效。我们进一步展示了使用HM中的自定义策略的改进，这在Linux中很难应用（第2.3节）。
···帧丢失。图11d显示了在运行第3.1节中的典型使用模型的20轮中帧丢失次数（对用户体验至关重要）。由于负载更轻和HM中的自定义QoS引导调度，帧丢失比Linux少10%，更稳定20%。
···中断延迟。图11e和11f显示了播放视频和音频时相关中断的延迟CDF，这对于用户体验至关重要。HM通过使用自定义体验优先策略减少了它们的延迟，该策略一次性执行所有处理程序，在Linux中由于ARM GIC的延迟禁用而在另一个附加中断中处理。
···智能路由器和智能车辆中的经验。在智能路由器中，HM将操作系统内存占用减少了30%，允许多30%的客户端连接。在智能车辆中，HM将系统冷启动时间从1.5s（Linux）减少到0.6s（对用户体验至关重要，例如，启用360度环视），并将跨域（仪表盘和娱乐）通信延迟从250µs降低到100µs。
