1*4882a593Smuzhiyun.. _page_owner: 2*4882a593Smuzhiyun 3*4882a593Smuzhiyun================================================== 4*4882a593Smuzhiyunpage owner: Tracking about who allocated each page 5*4882a593Smuzhiyun================================================== 6*4882a593Smuzhiyun 7*4882a593SmuzhiyunIntroduction 8*4882a593Smuzhiyun============ 9*4882a593Smuzhiyun 10*4882a593Smuzhiyunpage owner is for the tracking about who allocated each page. 11*4882a593SmuzhiyunIt can be used to debug memory leak or to find a memory hogger. 12*4882a593SmuzhiyunWhen allocation happens, information about allocation such as call stack 13*4882a593Smuzhiyunand order of pages is stored into certain storage for each page. 14*4882a593SmuzhiyunWhen we need to know about status of all pages, we can get and analyze 15*4882a593Smuzhiyunthis information. 16*4882a593Smuzhiyun 17*4882a593SmuzhiyunAlthough we already have tracepoint for tracing page allocation/free, 18*4882a593Smuzhiyunusing it for analyzing who allocate each page is rather complex. We need 19*4882a593Smuzhiyunto enlarge the trace buffer for preventing overlapping until userspace 20*4882a593Smuzhiyunprogram launched. And, launched program continually dump out the trace 21*4882a593Smuzhiyunbuffer for later analysis and it would change system behaviour with more 22*4882a593Smuzhiyunpossibility rather than just keeping it in memory, so bad for debugging. 23*4882a593Smuzhiyun 24*4882a593Smuzhiyunpage owner can also be used for various purposes. For example, accurate 25*4882a593Smuzhiyunfragmentation statistics can be obtained through gfp flag information of 26*4882a593Smuzhiyuneach page. It is already implemented and activated if page owner is 27*4882a593Smuzhiyunenabled. Other usages are more than welcome. 28*4882a593Smuzhiyun 29*4882a593Smuzhiyunpage owner is disabled in default. So, if you'd like to use it, you need 30*4882a593Smuzhiyunto add "page_owner=on" into your boot cmdline. If the kernel is built 31*4882a593Smuzhiyunwith page owner and page owner is disabled in runtime due to no enabling 32*4882a593Smuzhiyunboot option, runtime overhead is marginal. If disabled in runtime, it 33*4882a593Smuzhiyundoesn't require memory to store owner information, so there is no runtime 34*4882a593Smuzhiyunmemory overhead. And, page owner inserts just two unlikely branches into 35*4882a593Smuzhiyunthe page allocator hotpath and if not enabled, then allocation is done 36*4882a593Smuzhiyunlike as the kernel without page owner. These two unlikely branches should 37*4882a593Smuzhiyunnot affect to allocation performance, especially if the static keys jump 38*4882a593Smuzhiyunlabel patching functionality is available. Following is the kernel's code 39*4882a593Smuzhiyunsize change due to this facility. 40*4882a593Smuzhiyun 41*4882a593Smuzhiyun- Without page owner:: 42*4882a593Smuzhiyun 43*4882a593Smuzhiyun text data bss dec hex filename 44*4882a593Smuzhiyun 48392 2333 644 51369 c8a9 mm/page_alloc.o 45*4882a593Smuzhiyun 46*4882a593Smuzhiyun- With page owner:: 47*4882a593Smuzhiyun 48*4882a593Smuzhiyun text data bss dec hex filename 49*4882a593Smuzhiyun 48800 2445 644 51889 cab1 mm/page_alloc.o 50*4882a593Smuzhiyun 6662 108 29 6799 1a8f mm/page_owner.o 51*4882a593Smuzhiyun 1025 8 8 1041 411 mm/page_ext.o 52*4882a593Smuzhiyun 53*4882a593SmuzhiyunAlthough, roughly, 8 KB code is added in total, page_alloc.o increase by 54*4882a593Smuzhiyun520 bytes and less than half of it is in hotpath. Building the kernel with 55*4882a593Smuzhiyunpage owner and turning it on if needed would be great option to debug 56*4882a593Smuzhiyunkernel memory problem. 57*4882a593Smuzhiyun 58*4882a593SmuzhiyunThere is one notice that is caused by implementation detail. page owner 59*4882a593Smuzhiyunstores information into the memory from struct page extension. This memory 60*4882a593Smuzhiyunis initialized some time later than that page allocator starts in sparse 61*4882a593Smuzhiyunmemory system, so, until initialization, many pages can be allocated and 62*4882a593Smuzhiyunthey would have no owner information. To fix it up, these early allocated 63*4882a593Smuzhiyunpages are investigated and marked as allocated in initialization phase. 64*4882a593SmuzhiyunAlthough it doesn't mean that they have the right owner information, 65*4882a593Smuzhiyunat least, we can tell whether the page is allocated or not, 66*4882a593Smuzhiyunmore accurately. On 2GB memory x86-64 VM box, 13343 early allocated pages 67*4882a593Smuzhiyunare catched and marked, although they are mostly allocated from struct 68*4882a593Smuzhiyunpage extension feature. Anyway, after that, no page is left in 69*4882a593Smuzhiyunun-tracking state. 70*4882a593Smuzhiyun 71*4882a593SmuzhiyunUsage 72*4882a593Smuzhiyun===== 73*4882a593Smuzhiyun 74*4882a593Smuzhiyun1) Build user-space helper:: 75*4882a593Smuzhiyun 76*4882a593Smuzhiyun cd tools/vm 77*4882a593Smuzhiyun make page_owner_sort 78*4882a593Smuzhiyun 79*4882a593Smuzhiyun2) Enable page owner: add "page_owner=on" to boot cmdline. 80*4882a593Smuzhiyun 81*4882a593Smuzhiyun3) Do the job what you want to debug 82*4882a593Smuzhiyun 83*4882a593Smuzhiyun4) Analyze information from page owner:: 84*4882a593Smuzhiyun 85*4882a593Smuzhiyun cat /sys/kernel/debug/page_owner > page_owner_full.txt 86*4882a593Smuzhiyun ./page_owner_sort page_owner_full.txt sorted_page_owner.txt 87*4882a593Smuzhiyun 88*4882a593Smuzhiyun See the result about who allocated each page 89*4882a593Smuzhiyun in the ``sorted_page_owner.txt``. 90