RE: [PATCH] new irq tracer


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.


-----Original Message-----
From: Steven Rostedt [mailto:rostedt@xxxxxxxxxxx]
Sent: 25-Feb-09 20:42
To: Mathieu Desnoyers
Cc: Frederic Weisbecker; Jason Baron; Masami Hiramatsu;
KOSAKI Motohiro; Peter Zijlstra; Frank Ch. Eigler;
mingo@xxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
acme@xxxxxxxxxxxxxxxxxx; Dominique Toupin
Subject: Re: [PATCH] new irq tracer


On Wed, 25 Feb 2009, Mathieu Desnoyers wrote:

Then use the function_graph tracer.


Sadly, the function tracer cannot be enabled on
production systems.
Therefore it's not a usable solution in the context
where I need this.

Mathieu


Why?
If this is about the interrupt latency caused by
stop_machine, I still don't understand.
This latency happens before the tracing (function filter
which use
patching), not during tracing.


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.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • [ANNOUNCE] RTAI/fusion real-time extension
    ... Introducing RTAI/fusion, a real-time extension to Linux 2.6. ... the various discussions on the low latency and real-time Linux issues, ...
    (Linux-Kernel)
  • Re: hardware geeks and software geeks
    ... > There are certainly applications where a standard platform running Linux ... > the operating systems are being tuned for more responsiveness. ... a system to play MP3 files is a soft real-time system. ... >> Bernd said that real-time embedded hardware geeks ...
    (comp.lang.forth)
  • Re: RTAI vs RTLinuxFree vs 2.6 Kernel + RT Pre-emption patch
    ... The proper use of the term "real-time" means that your system has dead-lines and the dead-lines must be met. ... Also when you deal with a kernel like Linux, you'll find that the response to interrupts can be fast when the system is not loaded but as the system goes through busy spurts then the response time may become a couple of order of magnitudes larger. ...
    (comp.realtime)
  • Re: Serial CPLD
    ... bit-banging the protocol is too much to expect of the ... Linux nor ARM in such detail to be able to tell, ... sensitive to interrupt latency. ...
    (comp.arch.embedded)
  • Re: [SLE] Developing a Real Time Data System
    ... >functions with linux as a subordinate module. ... >Even with the specialized additions to make linux or Windows real-time, ... data from a Data Acquisition Card. ... This card just get an analog input that can vary from –10 volts to –10 volts ...
    (SuSE)