1 ============================ 1 ============================
2 Subsystem Trace Points: kmem 2 Subsystem Trace Points: kmem
3 ============================ 3 ============================
4 4
5 The kmem tracing system captures events relate 5 The kmem tracing system captures events related to object and page allocation
6 within the kernel. Broadly speaking there are 6 within the kernel. Broadly speaking there are five major subheadings.
7 7
8 - Slab allocation of small objects of unknow 8 - Slab allocation of small objects of unknown type (kmalloc)
9 - Slab allocation of small objects of known 9 - Slab allocation of small objects of known type
10 - Page allocation 10 - Page allocation
11 - Per-CPU Allocator Activity 11 - Per-CPU Allocator Activity
12 - External Fragmentation 12 - External Fragmentation
13 13
14 This document describes what each of the trace 14 This document describes what each of the tracepoints is and why they
15 might be useful. 15 might be useful.
16 16
17 1. Slab allocation of small objects of unknown 17 1. Slab allocation of small objects of unknown type
18 ============================================== 18 ===================================================
19 :: 19 ::
20 20
21 kmalloc call_site=%lx ptr=%p b 21 kmalloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s
22 kmalloc_node call_site=%lx ptr=%p bytes_req 22 kmalloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d
23 kfree call_site=%lx ptr=%p 23 kfree call_site=%lx ptr=%p
24 24
25 Heavy activity for these events may indicate t 25 Heavy activity for these events may indicate that a specific cache is
26 justified, particularly if kmalloc slab pages 26 justified, particularly if kmalloc slab pages are getting significantly
27 internal fragmented as a result of the allocat 27 internal fragmented as a result of the allocation pattern. By correlating
28 kmalloc with kfree, it may be possible to iden 28 kmalloc with kfree, it may be possible to identify memory leaks and where
29 the allocation sites were. 29 the allocation sites were.
30 30
31 31
32 2. Slab allocation of small objects of known t 32 2. Slab allocation of small objects of known type
33 ============================================== 33 =================================================
34 :: 34 ::
35 35
36 kmem_cache_alloc call_site=%lx ptr=%p b 36 kmem_cache_alloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s
37 kmem_cache_alloc_node call_site=%lx ptr=%p b 37 kmem_cache_alloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d
38 kmem_cache_free call_site=%lx 38 kmem_cache_free call_site=%lx ptr=%p
39 39
40 These events are similar in usage to the kmall 40 These events are similar in usage to the kmalloc-related events except that
41 it is likely easier to pin the event down to a 41 it is likely easier to pin the event down to a specific cache. At the time
42 of writing, no information is available on wha 42 of writing, no information is available on what slab is being allocated from,
43 but the call_site can usually be used to extra 43 but the call_site can usually be used to extrapolate that information.
44 44
45 3. Page allocation 45 3. Page allocation
46 ================== 46 ==================
47 :: 47 ::
48 48
49 mm_page_alloc page=%p pfn=%lu orde 49 mm_page_alloc page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s
50 mm_page_alloc_zone_locked page=%p pfn=%lu or 50 mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d
51 mm_page_free page=%p pfn=%lu orde 51 mm_page_free page=%p pfn=%lu order=%d
52 mm_page_free_batched page=%p pfn=%lu orde 52 mm_page_free_batched page=%p pfn=%lu order=%d cold=%d
53 53
54 These four events deal with page allocation an 54 These four events deal with page allocation and freeing. mm_page_alloc is
55 a simple indicator of page allocator activity. 55 a simple indicator of page allocator activity. Pages may be allocated from
56 the per-CPU allocator (high performance) or th 56 the per-CPU allocator (high performance) or the buddy allocator.
57 57
58 If pages are allocated directly from the buddy 58 If pages are allocated directly from the buddy allocator, the
59 mm_page_alloc_zone_locked event is triggered. 59 mm_page_alloc_zone_locked event is triggered. This event is important as high
60 amounts of activity imply high activity on the 60 amounts of activity imply high activity on the zone->lock. Taking this lock
61 impairs performance by disabling interrupts, d 61 impairs performance by disabling interrupts, dirtying cache lines between
62 CPUs and serialising many CPUs. 62 CPUs and serialising many CPUs.
63 63
64 When a page is freed directly by the caller, t 64 When a page is freed directly by the caller, the only mm_page_free event
65 is triggered. Significant amounts of activity 65 is triggered. Significant amounts of activity here could indicate that the
66 callers should be batching their activities. 66 callers should be batching their activities.
67 67
68 When pages are freed in batch, the also mm_pag 68 When pages are freed in batch, the also mm_page_free_batched is triggered.
69 Broadly speaking, pages are taken off the LRU 69 Broadly speaking, pages are taken off the LRU lock in bulk and
70 freed in batch with a page list. Significant a 70 freed in batch with a page list. Significant amounts of activity here could
71 indicate that the system is under memory press 71 indicate that the system is under memory pressure and can also indicate
72 contention on the lruvec->lru_lock. 72 contention on the lruvec->lru_lock.
73 73
74 4. Per-CPU Allocator Activity 74 4. Per-CPU Allocator Activity
75 ============================= 75 =============================
76 :: 76 ::
77 77
78 mm_page_alloc_zone_locked page=%p pfn=%l 78 mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d
79 mm_page_pcpu_drain page=%p pfn=%l 79 mm_page_pcpu_drain page=%p pfn=%lu order=%d cpu=%d migratetype=%d
80 80
81 In front of the page allocator is a per-cpu pa 81 In front of the page allocator is a per-cpu page allocator. It exists only
82 for order-0 pages, reduces contention on the z 82 for order-0 pages, reduces contention on the zone->lock and reduces the
83 amount of writing on struct page. 83 amount of writing on struct page.
84 84
85 When a per-CPU list is empty or pages of the w 85 When a per-CPU list is empty or pages of the wrong type are allocated,
86 the zone->lock will be taken once and the per- 86 the zone->lock will be taken once and the per-CPU list refilled. The event
87 triggered is mm_page_alloc_zone_locked for eac 87 triggered is mm_page_alloc_zone_locked for each page allocated with the
88 event indicating whether it is for a percpu_re 88 event indicating whether it is for a percpu_refill or not.
89 89
90 When the per-CPU list is too full, a number of 90 When the per-CPU list is too full, a number of pages are freed, each one
91 which triggers a mm_page_pcpu_drain event. 91 which triggers a mm_page_pcpu_drain event.
92 92
93 The individual nature of the events is so that 93 The individual nature of the events is so that pages can be tracked
94 between allocation and freeing. A number of dr 94 between allocation and freeing. A number of drain or refill pages that occur
95 consecutively imply the zone->lock being taken 95 consecutively imply the zone->lock being taken once. Large amounts of per-CPU
96 refills and drains could imply an imbalance be 96 refills and drains could imply an imbalance between CPUs where too much work
97 is being concentrated in one place. It could a 97 is being concentrated in one place. It could also indicate that the per-CPU
98 lists should be a larger size. Finally, large 98 lists should be a larger size. Finally, large amounts of refills on one CPU
99 and drains on another could be a factor in cau 99 and drains on another could be a factor in causing large amounts of cache
100 line bounces due to writes between CPUs and wo 100 line bounces due to writes between CPUs and worth investigating if pages
101 can be allocated and freed on the same CPU thr 101 can be allocated and freed on the same CPU through some algorithm change.
102 102
103 5. External Fragmentation 103 5. External Fragmentation
104 ========================= 104 =========================
105 :: 105 ::
106 106
107 mm_page_alloc_extfrag page=%p pfn=%l 107 mm_page_alloc_extfrag page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d
108 108
109 External fragmentation affects whether a high- 109 External fragmentation affects whether a high-order allocation will be
110 successful or not. For some types of hardware, 110 successful or not. For some types of hardware, this is important although
111 it is avoided where possible. If the system is 111 it is avoided where possible. If the system is using huge pages and needs
112 to be able to resize the pool over the lifetim 112 to be able to resize the pool over the lifetime of the system, this value
113 is important. 113 is important.
114 114
115 Large numbers of this event implies that memor 115 Large numbers of this event implies that memory is fragmenting and
116 high-order allocations will start failing at s 116 high-order allocations will start failing at some time in the future. One
117 means of reducing the occurrence of this event 117 means of reducing the occurrence of this event is to increase the size of
118 min_free_kbytes in increments of 3*pageblock_s 118 min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where
119 pageblock_size is usually the size of the defa 119 pageblock_size is usually the size of the default hugepage size.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.