Tracing allocators of virtual memory and main memory
Hi all If i want to trace the allocators of virtual memory and main memory of process using ftrace on which functions i need to enable the probe.? Currently i have enabled sys_mmap,sys_brk for virtual allocations and mm_page_alloc, kmalloc, kmem_cache_alloc for main memory allocation. Will this give me whole picture of virtual and main memory allocations.? Thanks Regards Sahil
On March 11, 2015 12:07:29 PM EDT, sahil aggarwal <sahil.agg15@gmail.com> wrote:
Hi all
If i want to trace the allocators of virtual memory and main memory of process using ftrace on which functions i need to enable the probe.?
Currently i have enabled sys_mmap,sys_brk for virtual allocations and mm_page_alloc, kmalloc, kmem_cache_alloc for main memory allocation. Will this give me whole picture of virtual and main memory allocations.?
Thanks Regards Sahil
______ Greetings Sachil, The best way to do this is find out the PID of your application and look for it in /proc as there should be a directory with the information your looking for. Nick Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi Nicholas Yeah right, pidstat which read /proc gives me VSZ ans RSS but i need to backtrace when VSZ/RSS is high which indicates process is allocating memory which it is not even using. And to modify the question i need to analyze allocations per thread, using /proc will it will also include VSZ RSS of parent.? Regards Sahil Aggarwal
On Mar 11, 2015, at 11:00 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
On March 11, 2015 12:07:29 PM EDT, sahil aggarwal <sahil.agg15@gmail.com> wrote: Hi all
If i want to trace the allocators of virtual memory and main memory of process using ftrace on which functions i need to enable the probe.?
Currently i have enabled sys_mmap,sys_brk for virtual allocations and mm_page_alloc, kmalloc, kmem_cache_alloc for main memory allocation. Will this give me whole picture of virtual and main memory allocations.?
Thanks Regards Sahil
______ Greetings Sachil, The best way to do this is find out the PID of your application and look for it in /proc as there should be a directory with the information your looking for. Nick Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Thu, 12 Mar 2015 07:09:32 +0530, SAHIL said:
Yeah right, pidstat which read /proc gives me VSZ ans RSS but i need to backtrace when VSZ/RSS is high which indicates process is allocating memory which it is not even using.
Do you mean pages it isn't *currently* using, or has *never* used? Also, note that VSZ refers to the virtual size, which may include pages currently out on swap, while RSS refers to actually resident pages. And then there's the other great bugaboo, shared pages that are mapped by more than one process. What exactly are you trying to do?
Hi validis Actually i want to see how much total virtual pages it asked for and how many it actually used, how many were put to swap, how many major page faults happened and how many faults were handled from swap. In short whole page level analysis of thread. Regards Sahil Aggarwal Contact-9988439647
On Mar 12, 2015, at 7:24 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 12 Mar 2015 07:09:32 +0530, SAHIL said:
Yeah right, pidstat which read /proc gives me VSZ ans RSS but i need to backtrace when VSZ/RSS is high which indicates process is allocating memory which it is not even using.
Do you mean pages it isn't *currently* using, or has *never* used?
Also, note that VSZ refers to the virtual size, which may include pages currently out on swap, while RSS refers to actually resident pages.
And then there's the other great bugaboo, shared pages that are mapped by more than one process.
What exactly are you trying to do?
Sample Output: mem-3374 [005] 589012.489483: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489486: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489489: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489493: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489495: sys_brk -> 0x23f1000 mem-3374 [005] 589012.489500: kmem_cache_alloc: call_site=ffffffff810fda40 ptr=ffff880fbe4bf298 bytes_req=176 bytes_alloc=176 gfp_flags=GFP_KERNEL|GFP_ZERO mem-3374 [005] 589012.489501: sys_brk -> 0x2417000 mem-3374 [005] 589012.489504: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489511: mm_page_alloc: page=ffffea00375619f0 pfn=16578386 order=0 migratetype=0 gfp_flags=GFP_KERNEL|GFP_REPEAT|GFP_ZERO mem-3374 [005] 589012.489512: kmem_cache_alloc: call_site=ffffffff81101422 ptr=ffff880fb765b6a8 bytes_req=48 bytes_alloc=48 gfp_flags=GFP_KERNEL mem-3374 [005] 589012.489513: kmem_cache_alloc: call_site=ffffffff81101454 ptr=ffff880fbe4c63a0 bytes_req=64 bytes_alloc=64 gfp_flags=GFP_KERNEL mem-3374 [005] 589012.489518: mm_page_alloc: page=ffffea0034cccf00 pfn=15818528 order=0 migratetype=2 gfp_flags=GFP_HIGHUSER_MOVABLE|GFP_ZERO mem-3374 [005] 589012.489520: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=0 mem-3374 [005] 589012.489526: mm_page_alloc: page=ffffea0034b8d2e0 pfn=15795140 order=0 migratetype=2 gfp_flags=GFP_HIGHUSER_MOVABLE|GFP_ZERO mem-3374 [005] 589012.489527: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=0 mem-3374 [005] 589012.489534: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489536: mm_fault: (do_page_fault+0x3b3/0x3d8 <- handle_mm_fault) arg1=512 mem-3374 [005] 589012.489552: mark_page_acc: (unmap_vmas+0x553/0x812 <- mark_page_accessed) mem-3374 [005] 589012.489556: mark_page_acc: (unmap_vmas+0x553/0x812 <- mark_page_accessed) mem-3374 [005] 589012.489557: mark_page_acc: (unmap_vmas+0x553/0x812 <- mark_page_accessed) These are some lines of stats for a program which ask for 4096*5 bytes but dont touch them. If it touch those pages mm_page_alloc will increase. So is this correct way to capture brk,mmap and mm_page_alloc to analyze how much pages thread asked for and how many of it actually used.? Thank you Regards Sahil On 12 March 2015 at 08:40, SAHIL <sahil.agg15@gmail.com> wrote:
Hi validis
Actually i want to see how much total virtual pages it asked for and how many it actually used, how many were put to swap, how many major page faults happened and how many faults were handled from swap. In short whole page level analysis of thread.
Regards Sahil Aggarwal Contact-9988439647
On Mar 12, 2015, at 7:24 AM, Valdis.Kletnieks@vt.edu wrote:
On Thu, 12 Mar 2015 07:09:32 +0530, SAHIL said:
Yeah right, pidstat which read /proc gives me VSZ ans RSS but i need to backtrace when VSZ/RSS is high which indicates process is allocating memory which it is not even using.
Do you mean pages it isn't *currently* using, or has *never* used?
Also, note that VSZ refers to the virtual size, which may include pages currently out on swap, while RSS refers to actually resident pages.
And then there's the other great bugaboo, shared pages that are mapped by more than one process.
What exactly are you trying to do?
participants (4)
-
Nicholas Krause -
SAHIL -
sahil aggarwal
-
Valdis.Kletnieks＠vt.edu