Page 463 - 《软件学报》2025年第5期
P. 463

苏浩然 等: SPARC  架构下低时延微内核进程间通信设计                                                  2363


                 溃或被攻击者完全掌控. 微内核操作系统将大部分系统服务和功能迁移到内核外部, 作为用户态应用来提供服务,
                 普通的用户态应用可以通过进程间通信使用这些系统服务, 内核中则仅保留内存管理、线程调度、进程间通信等
                 最基本的功能, 以此提供了较强的可靠性与易演化性, 并在安全关键的场景中得到了成功应用                             [1−10] .
                    微内核提供的可靠性与航天等对可靠性要求很高的领域需求相契合, 因此在航天领域的设备控制系统上部署
                 微内核系统有助于为其系统整体的可靠性提供保障. 航天领域的控制系统广泛使用                            SPARC  架构处理器. 欧洲航
                 空局为航天设备开发了        ERC32 [11] 处理器, 后续又转为  LEON  系列处理器    [12,13] , 具有防辐射、高性能、低成本等特
                 性. 中国在航天设备上也大规模采用了自研的               SPARC  架构的  BM3803, BM3823  等处理器  [14] 以及  S698  系列处理
                 器  [15] . 目前, SPARC  架构的处理器在诸如航天飞船、卫星载荷、星球车以及空间站等航空航天设备上被使用, 占
                 据重要地位    [14,16−18] . 然而  SPARC  架构的一些架构特性却严重影响了微内核上        IPC (进程间通信) 的性能.
                    在微内核架构上, 各种系统服务和驱动都作为用户态进程运行, 因此应用程序必须通过                            IPC  才能与这些系统
                 服务进程通信, 进而能够调用这些系统服务. 此外, 系统服务之间可能存在依赖关系, 某个系统服务可能需要向其
                 他系统服务发送      IPC  来实现其功能. 比如应用程序调用文件系统接口, 可能需要向文件系统服务发送                       IPC, 而文件
                 系统服务可能又需要向硬盘相关的系统服务发送                  IPC, 在这一场景下, 微内核需要发生         4  次用户态与内核态之间
                 的切换, 而宏内核则仅需       1  次即可完成. 许多研究表明, IPC      带来的额外开销是微内核系统性能劣于宏内核的重要
                 因素之一   [19−25] .
                    许多工作    [24−35] 都曾专门对微内核   IPC  进行过优化, 其中一些工作利用了具体架构的特性, 但很少有工作关注
                 SPARC  架构上的   IPC. 在  SPARC  架构上运行微内核时, 其     IPC  性能往往较差, 这是由     SPARC  架构本身的寄存器
                 窗口特性导致的. SPARC      架构的所有通用整型寄存器以窗口形式组织, 每个窗口包含                   24  个寄存器可供使用, 相邻
                 窗口间有   8  个寄存器是重叠的, 因此函数调用可以通过滑动至下一个窗口来高效完成, 但其寄存器数量与窗口数
                 量成正比, 即使只有      8  个寄存器窗口也意味着有        136  个通用寄存器. 其大量的通用寄存器严重增加了微内核下用
                 户态进程进出内核以及线程切换时保存/恢复上下文开销                   [36] , 使得  IPC  性能较差. 我们观察到在现代处理器的高性
                 能背景下, SPARC   架构的寄存器窗口设计并不能对程序性能带来明显提升, 寄存器窗口设计所针对的优化目标——
                 函数调用也并不再是程序的性能瓶颈. 受文献              [37] 的寄存器组   (Register bank) 设计的启发, 我们提出了   BankedIPC,
                 其核心在于设计实现了在软件层面对             SPARC  架构寄存器窗口进行管理和分配的方法, 由微内核为每个线程分配
                 一个包含若干个寄存器窗口的寄存器组, 并允许多个线程的上下文同时位于寄存器中, 以大幅提升上下文切换性
                 能进而实现对     IPC  的性能优化. 对于需要传输的数据较少的            IPC, 可以直接使用寄存器传递这些数据以避免访存
                 开销, 从而提升性能. 然而在正常运行的过程中, SPARC             架构并没有像文献       [34] 中提到的   x86  架构里那样的空闲
                 寄存器用以存放这些       IPC  数据, 因此无法采用这一优化方法. 而在使用上述寄存器组的设计后, 相邻寄存器组之间
                 会产生一些冗余的空闲寄存器, 因此这些寄存器就能够被用来传递                      IPC  数据. 我们在采用寄存器组设计的同时, 使
                 用这些空闲寄存器传递        IPC  数据, 充分利用了    SPARC  架构提供的大量寄存器, 进一步提升了           SPARC  上微内核在
                 处理需要传输的数据较少的          IPC  时的性能.
                    测试发现, 在多核      SPARC  处理器上, 运行在不同      CPU  核心间的应用在进行跨核        IPC  时性能往往较差, 因此
                 本工作还针对跨核       IPC  进行了专门优化. 在多核处理器上, 一些应用并不会占用全部处理器核心资源, 因此我们从
                 文献  [38] 中得到启发, 提出了    FlexIPC, 令  IPC  的客户端线程和服务端线程运行在不同的处理器核心上, 并通过轮
                 询共享内存中特定标志位的方式转移控制流, 这样就可以避免传统                      IPC  进出内核带来的较大性能开销, 也能够防
                 止  SPARC  架构下性能较差的     IPI (核间中断) 影响跨核    IPC  的性能.
                    自研微内核     ChCore 上实现了通用的同步       IPC  机制, 与主流的微内核实现相比, ChCore 上的        IPC  具有较好的
                 性能  [35] . 本工作将  ChCore 移植到了  SPARC  架构上, 并在  ChCore 原有的  IPC  机制的基础上, 实现了前文所提的
                 对  IPC  的优化. 本工作在航天领域中使用的真实硬件上测试了在使用各类优化策略前后                        ChCore 上  IPC  的性能以
                 及调用用户态系统服务的性能, 验证了这些优化方法的有效性. 本文的主要贡献如下.
                    1) 提出了内核对     SPARC  架构寄存器窗口进行高效分配管理的设计方法, 设计了软件层面的寄存器组机制,
                 优化了   SPARC  架构下上下文切换的性能;
   458   459   460   461   462   463   464   465   466   467   468