[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0902262230130.19122@gandalf.stny.rr.com>
Date: Thu, 26 Feb 2009 22:36:01 -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:
> >
> > 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.
The reason I brought up the rt-patch is that Mathieu is concerned about
the small latency that happens when we run stop_machine to switch the nops
to pointers to trace functions. This latency can be a couple of millisecs,
but I can easily make a normal kernel suffer a couple of millisec latency
by simply running hackbench (as a normal user).
The point being, I think Mathieu's point about the latency of enabling the
function tracer is frivolous. It is a one time shot that happens when the
sysadmin purposely enables the function tracing. If this is unacceptable,
then the system had better be running the rt patch because it will be
hitting this unacceptable latency in normal operation.
-- 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