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

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


                 用寄存器组机制后, 则必须限制应用只能使用一个寄存器窗口, 这样每次函数调用时就必须将“被调用者保存
                 (callee-saved)”的寄存器保存到栈上, 从而带来额外的访存开销, 函数返回时同理. 在第                    2.1  节中, 我们测试了
                 nbench  中的应用在仅使用一个寄存器窗口时的性能损失情况, 测试结果如图                    2  所示, 这些应用程序为计算密集型,
                 基本不需要上下文切换, 其中大多数应用程序中性能下降都在                     2%  以内. 为了进一步明确函数调用带来的额外开
                 销有多少, 我们设计了简单的测试程序专门测试函数调用带来的额外开销, 测试程序中使用了简单的递归函数来
                 模拟调用链深度. 测试结果如图          10  所示. 正常情况下, 仅使用一个寄存器窗口时, 平均每次函数调用会带来约                   6  个
                 时钟周期的额外开销       (在运行测试的硬件平台上相当于大约             30 ns). 因此对于上下文切换      (包括线程切换、系统调
                 用、IPC  等) 次数较少且频繁发生函数调用的应用来说, 寄存器组机制的优化效果可能并不理想. 然而当函数调用
                 深度较高时, 使用多个寄存器窗口的开销反而超过了仅使用一个寄存器窗口, 这是因为当所有寄存器窗口都被使
                 用后, 如果再执行     SAVE  指令, 就会触发   trap, 需要将之前最早被使用过的寄存器窗口清空并保存到栈上, 从而获
                 得新的可供使用的寄存器窗口; 而对于仅使用一个寄存器窗口的应用来说, 不论其函数调用链有多深, 每次函数调
                 用的开销都是相似的. 所以对于函数调用层次较深的应用, 寄存器组带来的额外开销可以得到平衡.
                    (4) RQ4: FlexIPC  能对  ChCore 上的跨核  IPC  性能带来多少提升?
                    我们接下来测试了       FlexIPC  对跨核  IPC  的优化作用. 此次测试仍然采取前述的零数据            IPC  以关注控制流转移
                 的性能开销. 为了使用      FlexIPC, 测试程序将   IPC  服务端线程绑定在了单独的一个处理器核心上, 其余客户端线程
                 运行在其他核心上; 未优化的跨核          IPC  使用线程迁移实现, 其客户端线程平均分布在所有核心上. 测试结果如图                     11
                 所示. 可以看到, 即使当      IPC  并发数量很少时, 由于跨核      IPI 的性能问题, 基于线程迁移的        IPC  性能就远差于单核
                 的情况, 但  FlexIPC  可以非常有效地改善这一情况, 并发数较少时             FlexIPC  能够使跨核  IPC  的时延下降  86%. 随着
                 并发数量的增多, 由于原始版本的          IPC  性能瓶颈受限于     IPI 而并非并发数, 所以其性能下降并不严重, 此外由于服
                 务端只有一个线程在进行处理, 客户端线程增加时                FlexIPC  的性能也在逐步下降, 即使如此, 在        32  个  IPC  并发时,
                 FlexIPC  的时延仍然只有原来的      49%.

                     600                                           250
                                  Base   Register bank                   Base  FlexIPC
                                                                   225
                     500                                           200
                                                                   175
                    时延 (cycle)  400                              单次 IPC 时延 (μs)  150
                     300
                                                                   125
                                                                   100
                     200
                                                                   50
                     100                                           75
                                                                   25
                       0                                            0
                         1  2  3   4  5   6  7   8  9  10             0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
                                   函数调用链深度                                        IPC 并发数
                      图 10    寄存器组对函数调用的性能影响                           图 11    FlexIPC  时延测试结果

                    BankedIPC  和  FlexIPC  采用不同的思路对  IPC  性能进行优化. BankedIPC  的核心是使用内核的寄存器组机制
                 减少上下文切换开销, 而       FlexIPC  则是使用用户态轮询的思想避免绕过内核, 直接避免上下文切换的开销. 整体来
                 说, 由于  FlexIPC  必须独占一个处理器核心的资源, 且绕过了内核, 所以其性能提升相较                    BankedIPC  来说更加明
                 显, 尤其是在线程数量较少时, FlexIPC        可降低   86%  的时延而   BankedIPC  此时仅能降低约    20%  的时延. 但是在
                 IPC  请求不密集的时候, FlexIPC   服务端的轮询会导致处理器资源的浪费, 也会影响系统上其他应用程序的性能;
                 而  BankedIPC  则更加灵活, 对资源的利用率更高, 也对用户更加透明. 因此, FlexIPC            适用于对性能追求更高且需
                 要持续占用资源提供        IPC  服务的应用程序; 而    BankedIPC  则更加通用, 适用于需要按需处理         IPC  请求的场景. 虽
                 然  BankedIPC  主要针对单核场景, 但是也可在跨核         IPC  的场景下单独使用     BankedIPC, 不过这种方案的性能提升
                 并不明显, 原因是传统跨核        IPC  的性能瓶颈主要在于       IPI 而非上下文切换, 且跨核情况下无法利用到             BankedIPC
   471   472   473   474   475   476   477   478   479   480   481