[ltt-dev] ltt trace doesn't show event mm.page_alloc

[jwboyer@linux.vnet.ibm.com (Josh Boyer)]

On Mon, Jun 14, 2010 at 10:16:46AM -0700, Dany Madden wrote:
>Hi,
>
>Ltt trace doesn't show mm.page_alloc event with the mainline kernel:
>
>- mainline kernel 2.6.32.12
>- patch-2.6.32.9-lttng-0.198
>- ltt-control-0.79-01022010
>- lttv-0.12.30-02102010
>
>mm-trace.ko is loaded.
>
>ltt-armall output shows
>....
>Connecting /sys/kernel/debug/ltt/markers/mm/wait_on_page_start
>Connecting /sys/kernel/debug/ltt/markers/mm/wait_on_page_end
>Connecting /sys/kernel/debug/ltt/markers/mm/huge_page_free
>Connecting /sys/kernel/debug/ltt/markers/mm/huge_page_alloc
>Connecting /sys/kernel/debug/ltt/markers/mm/page_free
>Connecting /sys/kernel/debug/ltt/markers/mm/page_alloc
>Connecting /sys/kernel/debug/ltt/markers/mm/swap_in
>Connecting /sys/kernel/debug/ltt/markers/mm/swap_out
>Connecting /sys/kernel/debug/ltt/markers/mm/swap_file_close
>Connecting /sys/kernel/debug/ltt/markers/mm/swap_file_open
>Connecting /sys/kernel/debug/ltt/markers/mm/add_to_page_cache
>Connecting /sys/kernel/debug/ltt/markers/mm/remove_from_page_cache
>...
>
>These are the steps to recreate the problem:
>% lttctl -C -w /tmp/trace4 trace4
>% # ** run a program that does a lot of malloc and free
>% lttctl -D trace4
>
># even mm.page_alloc is **not** showing in the trace
>% lttv -m textDump --fatal -e event.name=mm.page_alloc -t /tmp/trace4
>Trace set contains 1 traces
>
>End trace set
>
># even mm.page_free is showing in the trace.
>% lttv -m textDump --process_stats -e event.name=mm.page_free -t
>/tmp/trace4
>Trace set contains 1 traces
>...
>mm.page_free: 7334.057610863 (/tmp/trace4/mm_1), 6200, 6200, ./ltt_alloc, ,
>4962, 0x0, SYSCALL { pfn = 487653, order = 0 }
>mm.page_free: 7334.057612915 (/tmp/trace4/mm_1), 6200, 6200, ./ltt_alloc, ,
>4962, 0x0, SYSCALL { pfn = 510031, order = 0 }
>mm.page_free: 7334.057613190 (/tmp/trace4/mm_1), 6200, 6200, ./ltt_alloc, ,
>4962, 0x0, SYSCALL { pfn = 510030, order = 0 }
>...
>
>Please help look at this problem.

Dany and I discussed this a bit today.

It seems that the trace_page_alloc tracepoint is only placed in
__alloc_pages_slowpath, which is only called under memory reclaim conditions
from what I can tell.  The placement of trace_page_free seems spread to more
areas in the page free paths, so it gets picked up more broadly and shows up
in the trace.  Should the trace_page_alloc point be moved up to the
__alloc_pages_nodemask function or some other higher level allocation function?

Confusing the issue, or me at least, is that there is a trace_mm_page_alloc
call in the more general __alloc_pages_nodemask.  However, that call doesn't
seem to be an LTTng tracepoint so it doesn't register LTTng events in the
traces we see.  Is that perhaps an FTrace tracepoint?  There are other
functions in the mm/page_alloc.c file like this as well, such as
trace_mm_pagevec_free, and trace_mm_page_free_direct.  None of those generate
anything in the LTTng output either.

All of that is still true with the lttng-0.216 branch from what I can tell.

josh