【内存管理】【slab】/sys/kernel/slab/＜slab name＞/trace解析

目录

什么是/sys/kernel/slab//trace？

/sys/kernel/slab//trace的作用

/sys/kernel/slab//trace使用方法

---

什么是/sys/kernel/slab/<slab name>/trace？

首先是看下官方文档里的相关介绍：

https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-kernel-slab

What:		/sys/kernel/slab/cache/trace
Date:		May 2007
KernelVersion:	2.6.22
Contact:	Pekka Enberg <penberg@cs.helsinki.fi>,
		Christoph Lameter <cl@linux-foundation.org>
Description:
		The trace file specifies whether object allocations and frees
		should be traced.

说明：trace文件指定是否应跟踪对象的分配和释放。

通过trace文件，可以动态的去查看当前哪些函数申请和释放了具体的数据结构实例。

（Ps：先通过slabinfo查看有哪些对象，再进入到对应的目录下，查看该对象被调用的堆栈信息）

---

/sys/kernel/slab/<slab name>/trace的作用

• 通常我们首先通过/proc/slabinfo，查看当前的部分可能被频繁分配和释放的数据结构实例；
• 再通过/sys/kernel/slab，更详细的了解某一个具体的数据结构实例的分配和释放情况；
• /sys/kernel/slab/<slab name>/alloc_calls ，alloc_calls为只读文件，列出了从中执行此高速缓存分配的内核代码位置。
• /sys/kernel/slab/<slab name>/free_calls ，free_calls为只读文件，用来列举所有对象被释放的位置。
• /sys/kernel/slab/<slab name>/trace ，trace文件指定是否应跟踪对象的分配和释放。

通过trace文件，可以动态的去查看当前哪些函数申请和释放了具体的数据结构实例。

---

/sys/kernel/slab/<slab name>/trace使用方法

echo 1 > /sys/kernel/slab/<slab name>/trace  //开启trace追踪，slab会将该成员的所有调用栈信息打印出来
sleep 10
echo 0 > /sys/kernel/slab/<slab name>/trace  //因为开启trace追踪后，会不断的打印，需要重新设置trace为0后才会停止

Ps：因为开启trace可能导致系统输入输出无响应，关闭操作最好放到脚本中做

打印的slab trace大概长这样：

[ 1920.528920] TRACE kmalloc-4096 alloc 0xc2ec53c0 inuse=7 fp=0x  (null)
[ 1920.528927] CPU: 2 PID: 1904 Comm: ps Tainted: G           O   3.18.24_hi3798cv2x #1
[ 1920.528943] [<c0017b58>] (unwind_backtrace) from [<c00132b8>] (show_stack+0x20/0x24)
[ 1920.528951] [<c00132b8>] (show_stack) from [<c0d50af8>] (dump_stack+0x80/0xcc)
[ 1920.528961] [<c0d50af8>] (dump_stack) from [<c0112c60>] (alloc_debug_processing+0xc8/0x170)
[ 1920.528968] [<c0112c60>] (alloc_debug_processing) from [<c0113734>] (__slab_alloc.constprop.9+0x2e8/0x3bc)
[ 1920.528974] [<c0113734>] (__slab_alloc.constprop.9) from [<c0113a04>] (__kmalloc+0x1fc/0x224)
[ 1920.528980] [<c0113a04>] (__kmalloc) from [<c013edb4>] (seq_buf_alloc+0x20/0x44)
[ 1920.528984] [<c013edb4>] (seq_buf_alloc) from [<c013f41c>] (seq_read+0x314/0x4a0)
[ 1920.528990] [<c013f41c>] (seq_read) from [<c011c7fc>] (vfs_read+0x9c/0x15c)
[ 1920.528995] [<c011c7fc>] (vfs_read) from [<c011ce0c>] (SyS_read+0x54/0xb0)
[ 1920.529002] [<c011ce0c>] (SyS_read) from [<c000edc0>] (ret_fast_syscall+0x0/0x38)
[ 1920.529296] TRACE kmalloc-4096 free 0xc2ec53c0 inuse=7 fp=0x  (null)
[ 1920.529301] Object c2ec53c0: 2f 64 61 74 61 2f 6d 65 64 69 61 20 2f 73 74 6f  /data/media /sto
[ 1920.529304] Object c2ec53d0: 72 61 67 65 2f 65 6d 75 6c 61 74 65 64 20 73 64  rage/emulated sd
...
[ 1920.529935] Object c2ec63b0: 2f 73 2f 6d 6e 74 2f 73 64 61 2f 73 64 61 31 00  /s/mnt/sda/sda1.
[ 1920.529939] CPU: 2 PID: 1904 Comm: ps Tainted: G           O   3.18.24_hi3798cv2x #1
[ 1920.529950] [<c0017b58>] (unwind_backtrace) from [<c00132b8>] (show_stack+0x20/0x24)
[ 1920.529957] [<c00132b8>] (show_stack) from [<c0d50af8>] (dump_stack+0x80/0xcc)
[ 1920.529966] [<c0d50af8>] (dump_stack) from [<c01121d8>] (free_debug_processing+0x208/0x324)
[ 1920.529972] [<c01121d8>] (free_debug_processing) from [<c0114150>] (__slab_free+0x2a4/0x408)
[ 1920.529978] [<c0114150>] (__slab_free) from [<c0114774>] (kfree+0x218/0x22c)
[ 1920.529985] [<c0114774>] (kfree) from [<c00e8eec>] (kvfree+0x48/0x58)
[ 1920.529992] [<c00e8eec>] (kvfree) from [<c013f5c8>] (seq_release+0x20/0x30)
[ 1920.529999] [<c013f5c8>] (seq_release) from [<c0158dd4>] (mounts_release+0x3c/0x40)
[ 1920.530005] [<c0158dd4>] (mounts_release) from [<c011da40>] (__fput+0x90/0x1e0)
[ 1920.530010] [<c011da40>] (__fput) from [<c011dc00>] (____fput+0x18/0x1c)
[ 1920.530017] [<c011dc00>] (____fput) from [<c003bd24>] (task_work_run+0xb8/0xf4)
[ 1920.530024] [<c003bd24>] (task_work_run) from [<c0012b5c>] (do_work_pending+0xa4/0xc4)
[ 1920.530030] [<c0012b5c>] (do_work_pending) from [<c000ee08>] (work_pending+0xc/0x20)

---