1. 程式人生 > 其它 >【記憶體管理】【slab】/sys/kernel/slab/<slab name>/trace解析

【記憶體管理】【slab】/sys/kernel/slab/<slab name>/trace解析

技術標籤:深入理解Linux核心# 記憶體管理核心linux記憶體管理slabtrace

目錄

什麼是/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 <
[email protected]
>, Christoph Lameter <[email protected]> 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)