为什么自己编译的linux内核和驱动比系统自带的要大的多？？

1、配置中有很多调试选项（不一定带“debug”字样），而且位置也很分散；2、发行版自带内核往往经过长期、仔细的配置，会比个人十几分钟的配置更全面。这两个原因对内核及模块的大小有影响，但不大。编译出的内核模块中包含多个运行时用不到的段（编译连接时可能要用，不是错误），发行版中一般会删掉，这很有可能是原因所在。可以考虑用 [strip -S mod_name.ko] 来处理一下内核模块（注意：这里选项要用大写S，小写s或不写会连符号表一起删掉，导致模块无法加载），看看文件有没有变小（别对内核本身这么干）。如果以上命令明显减小了文件，可以考虑在编译内核前定义环境变量INSTALL_MOD_STRIP为1（数字），这样make modules_install后的内核模块都是经 strip 处理过的了。

假如通过“Free”查看内存几乎耗尽，但通过 top/ps 命令却看不出来用户态应用程序占用太多的内存空间， 那么内核模块可能发生了内存泄露

SLAB 是Linux内核中按照对象大小进行分配的内存分配器。

通过SLAB的信息来查看内核模块占用的内存空间：

方法1. 查看meminfo文件

方法2. 查看slabinfo文件

一般查看slabinfo文件就足以，如果发现slabinfo中占用内存过大，那基本可以断定，内核模块出现了内存泄露了

还有个命令 slabinfo 也是可以看，其实也是去读 /proc/slabinfo 后可视化出来

Linux内核的Kmemleak实现内存泄露检测

看看下面这个函数是哪里导致的内存泄漏呢？

一眼可能不容易看出上面的有什么问题，有kmalloc，有kfree 成对出现的。

问题正好出在 pr_debug 这个函数中的参数传递， 熟悉函数调用传参的人应该会知道编译器一般对参数的处理采用堆栈的方式，是一个先进后出的过程，这样参数的执行一般是逆序的（由于编译器实现的不同，这个过程不是确定的），这样kfree会在kmalloc之前运行，导致每次运行都会泄漏一点内存。

Resolving Memory Leaks In Linux Kernel

Slab Allocator

Proc Info

Using Crash Debugger

---