文章讨论了在SMP环境下，RTP程序在VxWorks操作系统上运行时遇到的CPU负载不均问题，尤其是内存分配和释放操作导致的互斥信号量竞争。提到了Windows平台的对比以及VxWorks的Memorycachingcomponent如何通过任务私有数据结构减少锁的竞争，优化小块内存的分配和释放。文章还探讨了可能的优化策略，包括参数调整、建立用户层内存池和减少malloc/free操作的频率。
现象描述：
SMP下 RTP程序跑在Core 4核的处理器上，测试RTP程序内创建了1000个任务（线程），每个任务会有一些涉及到内存申请（malloc）和释放（free）的操作，如STL vector的操作（任务间无互斥，vector为栈上对象），测试下来查看CPU占用率大概在30%左右，cpu spy查看4核CPU负载，明显地，CPU 0 出现了较高负载现象，其余核心负载较低。Suspend所有任务查看堆栈，发现几乎所有任务都在等待同一个互斥信号量，这个互斥信号量是VxWorks内部Mem Partition Alloc/Free调用的，应该是内存池的同一个分区内出现了大量申请和释放的操作，造成大量互斥现象的。
同样的测试在Windows上进行，可以发现，Windows的CPU可以达到近乎多核满载的效果。看上去应该是VxWorks本身的内存管理对于多核不太友好（如同一内存区管理只用了一个互斥信号量，没有再做分区，去实现负载平衡），当然实际应用应该尽量避免高频次的内存分配释放去提升CPU的利用率。
那么，针对此现象，目前有三个方向
① 是否参数配置不合理，导致内存分配效率较低，如果不合理，如何改善
② 是否需要建立用户层的内存池，建立多个内存池，针对不同的内存申请释放位置进行优化，避免内存申请释放时阻塞在同一互斥信号量中
③ 减小用户层的malloc/free频次
针对①方向，查阅了相关文档，发现VxWorks，配置中有Memory caching component，该库提供了VxWorks内核堆管理器memPartLib的扩展，以提高经常执行动态内存分配的任务的执行速度。通过将争用减少到堆管理器的关键部分（由互斥信号量序列化）来实现加速。减少这种争用在多核（SMP）系统上尤为重要。该实现依赖于任务私有数据结构，因此任务通常可以分配和释放内存块，而无需使用锁。从概念上讲，这相当于内存块的缓存，可以在需要时快速重用。支持malloc / free的块大小如下：
-
编号 块大小 适用块范围大小 ----- ------------ ----------------------- 0 16 bytes 0 - 16 bytes 1 32 bytes 17 - 32 bytes 2 48 bytes 33 - 48 bytes 3 64 bytes 48 - 64 bytes 4 80 bytes 65 - 80 bytes 5 96 bytes 81 - 96 bytes 6 112 bytes 97 - 112 bytes 7 128 bytes 113 - 128 bytes 8 160 bytes 129 - 160 bytes 9 192 bytes 161 - 192 bytes a 224 bytes 193 - 224 bytes b 256 bytes 225 - 256 bytes c 320 bytes 257 - 320 bytes d 384 bytes 321 - 384 bytes e 448 bytes 385 - 448 bytes f 512 bytes 449 - 512 bytes
最大支持分配512字节空间，每种块最大支持8组，超过这两种限制的任一种情况时，仍会在系统Heap上进行分配。这一点比较可惜，毕竟不同的任务分配需求都有所不同，也许是VxWorks为了方便管理，这一Cache空间的大小，在创建任务时就会分配完成，但是有总比没有强，经过测试，在vector容量小于8时，1000条任务，确实不会再出现争夺互斥信号资源的现象，如果程序中经常使用std::string，或者申请一些堆上的短小资源且数量不多时（即使分组超过，有一部分也会存在在Cache中），可以考虑开启这个功能。会对程序运行效率有提升效果。
扫一扫
779
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
