On Tue, Aug 31, 2010 at 12:53 AM, Mel Gorman <mel@xxxxxxxxx> wrote: > 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. Ok. I tried the logging and it works better this time. Both pagealloc and vmscan give me some data with the filtering works ok. thanks for your replay :) --Ying >> 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