[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0902262223550.19122@gandalf.stny.rr.com>
Date: Thu, 26 Feb 2009 22:29:56 -0500 (EST)
From: Steven Rostedt <rostedt@...dmis.org>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
cc: Dominique Toupin <dominique.toupin@...csson.com>,
Mathieu Desnoyers <compudj@...stal.dyndns.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Jason Baron <jbaron@...hat.com>,
Masami Hiramatsu <mhiramat@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"Frank Ch. Eigler" <fche@...hat.com>, mingo@...e.hu,
linux-kernel@...r.kernel.org, acme@...stprotocols.net
Subject: Re: [PATCH] new irq tracer
On Fri, 27 Feb 2009, KOSAKI Motohiro wrote:
> > > > Given this scenario :
> > > >
> > > > A telecommunication system runs, but the client notices
> > > something wrong.
> > > > They call their service provider. The provider enables tracing
> > > > _remotely_ on the _production system_ while it's _active in
> > > the field_.
> > > >
> > > > Bam, those few milliseconds interrupt latencies become unacceptable.
> > > >
> > > > Hopefully this scenario makes the use-case clearer. The
> > > problem is not
> > > > that interrupt latencies would occur while tracing is on,
> > > but rather
> > > > that it would happen on a running production system when switching
> > > > tracing on. This is what is totally unacceptable for this use-case.
> > > >
> > > > For more details about such requirements, I'm CCing
> > > Dominique Toupin
> > > > from Ericsson who I'm sure would be happy to give more
> > > details about
> > > > this if needed.
> > >
> > > Hmm, so this system in the field is running Linux with the
> > > Real-Time Patch? Because if it isn't it will suffer from
> > > millisecond latencies in normal operation.
> >
> > In many cases we don't use Linux real-time, we have many systems that
> > are soft-real-time an non real-time Linux is good enough.
> >
>
> Agreed, rt-patch seems off topics. we discuss to mainline kernel.
>
> Steven, I sitll think nobody use ftrace on production system now yet.
> Do you know actual production user?
First lets separate out "ftrace" and the function tracer. ftrace is the
infrastructure that has schedule tracing, event tracing and lots and lots
of other kinds of tracing.
The "stop_machine" talked about in this thread is specific for
dynamic_ftrace (which is used for the function and graph tracers).
Your question about "production user" is a little unfair, since function
tracing did not appear till 2.6.28. (I'm ignoring 2.6.27, since the
version of the function tracer there had a notorious bug).
No distribution is shipping a production 2.6.28 AFIAK. Which means, I do
not know of any production use of the function tracer. I have already
recommended that people enable the function tracer if they are using
2.6.28 in a production environment. Given some time, when 2.6.28 is more
in use, my answer would probably be "Yes, I do know it is used in a
production environment".
-- Steve
--
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