2,179
社区成员
现象描述:
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中),可以考虑开启这个功能。会对程序运行效率有提升效果。
还有一点,测试C++ STL部分的一些实现和Windows的也不太一样,测试代码如下:
vector a;
a.reserve(2000);
a.push_back(1);
a.clear();
printf("reserve capacity is %d\n", a.capacity());
Windows的打印结果是:reserve capacity is 2000
VxWorks的打印结果是:reserve capacity is 0
显然,预分配的内存会被clear删除掉,这一点在做移植的时候,如果程序对预分配做过优化,移植后优化的效果可能也不尽人意