On Tue, 11 Mar 2014 11:34:18 +0100 Mats Liljegren <liljegren.ma...@gmail.com> wrote:
> I have given the "correct" way of counting ticks some thought, but I > haven't come to a good conclusion. My current best bet is using > function tracing on scheduler_tick(). It seems to be the most > configuration and architecture independent way. But I'm not entirely > sure it really is just one call for each tick. If you have better > suggestions, I'd love to hear about it. Try this: echo 1 > /sys/kernel/debug/tracing/max_graph_depth echo function_graph > /sys/kernel/debug/tracing/current_tracer If CPU 5 is the one running with nohz, then monitor: /sys/kernel/debug/tracing/per_cpu/cpu5/trace_pipe And see what goes into the kernel. The "max_graph_depth" is the max depth the function_graph tracer should trace. By saying "1", you are telling it to give you the first function it sees, but ignore all the rest. I specifically implemented this because I thought it would be a great way to see what interrupts user tasks. Now if the user task does a syscall, you will only see that and not any tick that happened when the syscall was running. But you don't care about that anyway ;-) > > > I believe that trace-cmd unfortunately uses per CPU periodic wake up on live > > recording CPUs so perhaps it's not a good candidate to test isolation. Too > > bad > > because kernelshark is cool for an overview. > > I've invented a "count_ticks" script which hides ftrace complexity on > other interesting ways than trace_cmd does. It logs calls to > scheduler_tick during a command execution, and goes through this log > afterwards counting the calls. > > > Also perf supports some script languages for post processing: python, perl, > > etc... > > I think trace-cmd too but rather for custom display of events. > > While debugging is nice too, my first step is to just get something > that can say PASS/FAIL, with some information about why it failed > (e.g. because x ticks occurred that was not expected). Nothing more > fancy than that. I have scripts that test things like this. Not this exactly. All they are are bash scripts that read the trace file output and does simple parsing to see what happened during the test. And at the end, it simply says "PASS" or "FAIL". -- Steve ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
