[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5C4C569E8A4B9B42A84A977CF070A35B2C57F7A805@USINDEVS01.corp.hds.com>
Date: Wed, 14 Dec 2011 12:46:21 -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
>Well ftrace is a whole subsystem that includes the function tracer and also an interface
>for tracepoints in debugfs. I was rather suggesting the latter one. This is a good
>choice for background tracing. And it supports stacktraces. If those generate too much
>overhead perhaps you can tune the number of entries in the stacktrace, I don't remember
>if we can do that currently but this can be an interesting feature.
I would like to periodically check which function call is executed
rather than seeing stacktrace.
AFAIK, purpose of stack tracing is showing where the biggest use of the stack takes place.
I don't think stack tracing achieves my goal.
Rip in local timer interrupt is more accurate information
for achieving my goal than stacktrace
>
>What are you using currently for the background tracing?
Currently, we are using SystemTap in customer's system.
So, I would like to use this tracepoint with SystemTap.
--
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