当前位置: 技术问答>linux和unix
请教linux内核中的__purge_vmap_area_lazy函数
来源: 互联网 发布时间:2016-07-20
本文导语: 小弟最近在调一个系统(包括用户态程序和内核态驱动)的性能,发现有81%的时间在vmlinux中,而其中第一位的是90%的__purge_vmap_area_lazy函数,第二位的是3.8%的rb_next函数。 想来应该是内存管理上出了什么问题,但是小...
小弟最近在调一个系统(包括用户态程序和内核态驱动)的性能,发现有81%的时间在vmlinux中,而其中第一位的是90%的__purge_vmap_area_lazy函数,第二位的是3.8%的rb_next函数。
想来应该是内存管理上出了什么问题,但是小弟并没有研究过linux内核,只是在书上看到过段页式内存的基本介绍,还有就是知道每个进程4G空间中高端的1G空间分成内核直接映射区(用Kmalloc分配)和内核动态映射空间(用vmalloc函数分配)。所以,碰到这个问题没有了方向感,最基本的想法就是在内存分配释放的一些关键点增加log,看看有没有什么不对劲的地方,不过我也不知道这些关键点是什么,虽然大概理解这是slab分配器用红黑树数据结构在工作,减少碎片什么的。我也去匆匆翻过一些说linux内核内存管理的书本,感觉和这个具体问题的gap还是有一些大的。
好在我还有一个以前版本的系统,就是架构什么的发生了挺大变化,无法直接从代码层次进行比较。这个版本的性能比我在调的现在版本要好,vtune显示有88%的时间在vmlinux中,其中第一位的是60%的rb_next函数,第二位的是15%的__get_vm_area_node,而__purge_vmap_area_lazy则只占0.11%。我的目的就是把现在版本的性能调回到原先版本差不多的性能。
哪位高手有什么方向性的指点吗,虽然说有两个版本可以比较,只是我还没有找到怎么比较的有效方法,谢谢。
如果还能够抽出宝贵时间写一些更加系统的东西帮助理解,授我以渔,那就更感谢了。
想来应该是内存管理上出了什么问题,但是小弟并没有研究过linux内核,只是在书上看到过段页式内存的基本介绍,还有就是知道每个进程4G空间中高端的1G空间分成内核直接映射区(用Kmalloc分配)和内核动态映射空间(用vmalloc函数分配)。所以,碰到这个问题没有了方向感,最基本的想法就是在内存分配释放的一些关键点增加log,看看有没有什么不对劲的地方,不过我也不知道这些关键点是什么,虽然大概理解这是slab分配器用红黑树数据结构在工作,减少碎片什么的。我也去匆匆翻过一些说linux内核内存管理的书本,感觉和这个具体问题的gap还是有一些大的。
好在我还有一个以前版本的系统,就是架构什么的发生了挺大变化,无法直接从代码层次进行比较。这个版本的性能比我在调的现在版本要好,vtune显示有88%的时间在vmlinux中,其中第一位的是60%的rb_next函数,第二位的是15%的__get_vm_area_node,而__purge_vmap_area_lazy则只占0.11%。我的目的就是把现在版本的性能调回到原先版本差不多的性能。
哪位高手有什么方向性的指点吗,虽然说有两个版本可以比较,只是我还没有找到怎么比较的有效方法,谢谢。
如果还能够抽出宝贵时间写一些更加系统的东西帮助理解,授我以渔,那就更感谢了。
|
把内核版本报一下.
可以去国内的一个邮件列表交流: linux-kernel@zh-kernel.org
可以去国内的一个邮件列表交流: linux-kernel@zh-kernel.org
|
只能说说思路了,希望能帮上忙:
1. 检查__purge_vmap_area_lazy里面有什么改动,有没有些使函数执行时间变长的地方,看看能不能优化。
2. 如果1没有,那么就是__purge_vmap_area_lazy调用频率变多。
a. 分析一下执行环境,内存有没有变动?
b. 多核?看看是不是spin_lock等待时间太长?
1. 检查__purge_vmap_area_lazy里面有什么改动,有没有些使函数执行时间变长的地方,看看能不能优化。
2. 如果1没有,那么就是__purge_vmap_area_lazy调用频率变多。
a. 分析一下执行环境,内存有没有变动?
b. 多核?看看是不是spin_lock等待时间太长?
|
你可以使用kprobes来测试你的程序
内核源代码/Documentation/kprobes.txt是它的文档
可能对你的应用有用
内核源代码/Documentation/kprobes.txt是它的文档
可能对你的应用有用
|
你是什么应用?