[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5C4C569E8A4B9B42A84A977CF070A35B2C57F7A6D7@USINDEVS01.corp.hds.com>
Date: Wed, 14 Dec 2011 10:09:11 -0500
From: Seiji Aguchi <seiji.aguchi@....com>
To: Frederic Weisbecker <fweisbec@...il.com>
CC: Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Steven Rostedt <rostedt@...dmis.org>,
Michael Rubin <mrubin@...gle.com>,
David Sharp <dhsharp@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
Satoru Moriya <satoru.moriya@....com>
Subject: RE: [PATCH 2/2] trace,x86: Add x86 irq vector entry/exit tracepoints
Thank you for giving me a comment.
Unfortunately, neither "perf record" nor "ftrace" works for me.
>What about using perf for that?
>
>Just run:
>
> perf record -ag
> ^C
> perf report
>
>And you should find in the callchains some informations about where your CPUs
>are spending time.
>
>If you system is too slow for that
When system is too slow, user command such as "perf record" may not work.
>but you're doing background tracing with
>ftrace, you can use stacktrace with ftrace.
Actually, We're doing background tracing in our customer's system rather than kernel debugging.
Ftrace doesn't work for me because it checks the size of the stack at every function call.
Our customers are seriously concerned about its overhead.
For reducing the overhead, I need tracepoints so we can hook minimal function calls.
Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists