On Mon, Aug 30, 2010 at 04:10:05PM -0700, Ying Han wrote: > Hi Mel: > > I've been looking into the vmscan:tracing you added for 2.6.36_rc1. I > also backported into 2.6.34 which is the kernel we are currently > working on. However, I seems can not get it fully functional. Are you > aware of any changes on the kernel tracing ABI which could cause that > ? > Nothing springs to mind but ... > Here is how I reproduce it and I also attached the > postprocess/trace-vmscan-postprocess.pl I patched. > > # mount -t debugfs nodev /sys/kernel/debug/ > > # for i in `find /sys/kernel/debug/tracing/events -name "enable" | > grep mm_`; do echo 1 > $i; done > > run a process with pid==30196 > > # echo 'common_pid == 30196' > /sys/kernel/debug/tracing/events/vmscan/filter > > # cat /sys/kernel/debug/tracing/events/vmscan/filter > common_pid == 30196 > > # ./trace-vmscan-postprocess.pl < /sys/kernel/debug/tracing/trace_pipe > WARNING: Event vmscan/mm_vmscan_lru_shrink_inactive format string not found > WARNING: Event vmscan/mm_vmscan_lru_shrink_active format string not found > ^CSIGINT received, report pending. Hit ctrl-c again to exit > I didn't test the script for live processing. I was logging /sys/kernel/debug/tracing/trace_pipe to a file and post-processing it after a test. I suggest you do the same and check if any events for pid 30196 were recorded. > Reclaim latencies expressed as order-latency_in_ms > > Process Direct Wokeup Pages Pages Pages > Time > details Rclms Kswapd Scanned Sync-IO ASync-IO > Stalled > > Kswapd Kswapd Order Pages Pages Pages > Instance Wakeups Re-wakeup Scanned Sync-IO ASync-IO > > Summary > Direct reclaims: > Direct reclaim pages scanned: > Direct reclaim write file sync I/O: > Direct reclaim write anon sync I/O: > Direct reclaim write file async I/O: > Direct reclaim write anon async I/O: > Wake kswapd requests: > Time stalled direct reclaim: 0.00 seconds > > Kswapd wakeups: > Kswapd pages scanned: > Kswapd reclaim write file sync I/O: > Kswapd reclaim write anon sync I/O: > Kswapd reclaim write file async I/O: > Kswapd reclaim write anon async I/O: > Time kswapd awake: 0.00 seconds > > So it didn't give me any output. However, if I turn off the filter for > vmscan, it did give me some data but with random processes on the > system. > Did one of them processes include 30196 that you were filtering for? > The same set of tests works for trace-pagealloc-postprocess.pl though > > # cat /sys/kernel/debug/tracing/events/kmem/filter > common_pid == 30196 > > # ./trace-pagealloc-postprocess.pl < /sys/kernel/debug/tracing/trace_pipe > > Process Pages Pages Pages Pages PCPU > PCPU PCPU Fragment Fragment MigType Fragment Fragment Unknown > details allocd allocd freed freed pages > drains refills Fallback Causing Changed Severe Moderate > under lock direct pagevec drain > -30196 2871 2917 0 0 0 > 0 439 32 32 0 32 0 0 > ddtest-30196 4560 4328 0 0 0 > 0 639 26 26 1 25 1 0 > Maybe there were page allocator events and not vmscan events? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>