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 <[email protected]> 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, [email protected] 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?
_______________________________________________
Kernelnewbies mailing list
[email protected]
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
