Page 466 - 《软件学报》2025年第5期

2366 软件学报 2025 年第 36 卷第 5 期

1.02
使用全部窗口 仅使用一个窗口
1.00

0.98
吞吐率 0.96

0.94

0.92

0.90
Numeric sort String sort Bitfield FP emulation Fourier Assignment IDEA Huffman Neural net LU Interger index FP index
decomposition
图 2 nbench 测试结果

我们认为这一性能下降相比之后可进行的优化带来的收益来说是可以接受的. 在现代设备上, 与寄存器窗
口对函数调用带来的优化相比, 进出内核带来的性能损失更加难以接受, 对于频繁使用 IPC 的微内核系统而言
更是如此. 但是令应用程序仅使用一个寄存器窗口显然浪费了 SPARC 提供的大量寄存器, 因此我们可以针对寄
存器窗口的特性对内核进行重新设计与优化, 使内核掌握对全部寄存器窗口的分配和管理, 从而尽最大可能发
挥寄存器窗口机制提供的价值. SPARC V8 架构规范 [42] 就曾经提出减少线程对寄存器窗口的使用以提升上下文
切换性能的设计思想, 之后的 V9 规范 [43] 进一步实现了利用寄存器窗口的快速上下文切换, 而在文献 [44] 中提
出可以利用这一点来改进 IPC 性能. 文献 [37] 则是在架构设计层面提出了寄存器组 (Register bank) 的设计以提
升微内核系统性能, 而 SPARC 架构的寄存器窗口很适合采取这种寄存器组的设计. 受这一寄存器组的设计的启
发, 我们提出了在软件层面对 SPARC 架构寄存器窗口进行管理和分配的方法, 由微内核为每个线程分配一个包
含若干个寄存器窗口的寄存器组, 并允许多个线程的上下文同时位于寄存器中, 以大幅提升上下文切换性能进
而实现对 IPC 的性能优化.

2.2 使用寄存器传递 IPC 数据
在微内核架构的系统中, 系统服务作为用户态应用程序运行, 普通应用程序请求系统服务需要通过 IPC 来完
成, 因此微内核中 IPC 的使用有可能十分频繁. 自研微内核 ChCore 采取了共享内存的方式传递 IPC 数据, 即为
IPC 客户端和服务端分别映射一部分共享内存, 二者通过对共享内存进行读写以交换数据. 然而在多数场景下,
IPC 可能无需传递大量数据, 仅需传递少量参数. 文献 [34] 指出, 平均来说 50%–80% 的 IPC 仅需传递 8 个字节以
内的数据 (不包括发送者 ID), L4 [34] 就利用这一观察对这些传递数据量较小的 IPC 进行了高度优化, 实现了 IPC 的
快速路径, 其核心设计在于直接使用一些空闲的寄存器来传递 IPC 数据, 并且测试表明这能够将 IPC 时延降低至
原来的 48%. 我们在 S698PM 开发板上分别测试了使用内存和寄存器传递少量 IPC 参数时的性能, 结果如图 3 所
示, 由于在使用寄存器传递参数时, 不必判断参数数量, 可以简单地按照最大数量传递, 所以随着 IPC 负载的增加,
寄存器传参的性能基本不会变化; 而使用内存传递参数时, 性能则会随着负载的增加而逐渐下降, 此外, 即使在负
载为 0 时, 使用寄存器传参的性能也不会明显差于使用内存, 因为拷贝寄存器的开销相对于整个 IPC 过程来说是
可以忽略不计的. 但在某些架构下, 往往并没有较多空闲寄存器, 这使得 L4 的寄存器传参 IPC 应用场景受限, 如
果用户程序需要传递的数据量略大, 就无法利用这一 IPC 快速路径了. SPARC 架构下通用寄存器数量很多, 但传
统的 SPARC 架构上的通用操作系统一般不会对寄存器窗口进行手动管理, 应用程序会使用全部的寄存器窗口,
这样也就导致几乎没有空闲寄存器可用, 难以使用寄存器传递 IPC 数据. 如果微内核能够对 SPARC 的寄存器窗
口进行主动管理, 那么就可以充分利用其寄存器数量的优势, 从而可以专门预留一部分寄存器用于 IPC 参数传递,
尽可能实现零拷贝 IPC, 既能够为 IPC 寄存器数据传递提供更大的数据量支持, 也可以避免对其他应用程序的性
能产生较大影响.