Linux内核vmap函数,请教linux内核中的__purge_vmap_area_lazy函数

小弟最近在调一个系统(包括用户态程序和内核态驱动)的性能，发现有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-kernel@zh-kernel.org

|

只能说说思路了，希望能帮上忙：

1. 检查__purge_vmap_area_lazy里面有什么改动，有没有些使函数执行时间变长的地方，看看能不能优化。

2. 如果1没有，那么就是__purge_vmap_area_lazy调用频率变多。

a. 分析一下执行环境，内存有没有变动？

b. 多核？看看是不是spin_lock等待时间太长？

|

你可以使用kprobes来测试你的程序

内核源代码/Documentation/kprobes.txt是它的文档

可能对你的应用有用

|

你是什么应用？