I've implemented several mm tracepoints to track page allocation and
freeing, various types of pagefaults and unmaps, and critical page
reclamation routines. This is useful for debugging memory allocation
issues and system performance problems under heavy memory loads.
I have also addressed Rik van Riel's comments:
>It looks mostly good.
>
>I believe that the vmscan.c tracepoints could be a little
>more verbose though, it would be useful to know whether we
>are scanning anon or file pages and whether or not we're
>doing lumpy reclaim. Possibly the priority level, too.
----------------------------------------------------------------------
# tracer: mm
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
pdflush-624 [004] 184.293169: wb_kupdate:
(mm_pdflush_kupdate) count=3e48
pdflush-624 [004] 184.293439: get_page_from_freelist:
(mm_page_allocation) pfn=447c27 zone_free=1940910
events/6-33 [006] 184.962879: free_hot_cold_page:
(mm_page_free) pfn=44bba9
irqbalance-8313 [001] 188.042951: unmap_vmas:
(mm_anon_userfree) mm=ffff88044a7300c0 address=7f9a2eb70000 pfn=24c29a
cat-9122 [005] 191.141173: filemap_fault:
(mm_filemap_fault) primary fault: mm=ffff88024c9d8f40 address=3cea2dd000
pfn=44d68e
cat-9122 [001] 191.143036: handle_mm_fault:
(mm_anon_fault) mm=ffff88024c8beb40 address=7fffbde99f94 pfn=24ce22
...
Signed-off-by: Larry Woodman <[email protected]>
Larry Woodman wrote:
> Signed-off-by: Larry Woodman <[email protected]>
Acked-by: Rik van Riel <[email protected]>
--
All rights reversed.