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?