Message-ID: <41E8543A.8050304@am.sony.com>
Date: Fri, 14 Jan 2005 15:22:34 -0800
From: Tim Bird <tim.bird@am.sony.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: tglx@linutronix.de
CC: LKML <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.11-rc1-mm1
References: <20050114002352.5a038710.akpm@osdl.org> <1105742791.13265.3.camel@tglx.tec.linutronix.de>
In-Reply-To: <1105742791.13265.3.camel@tglx.tec.linutronix.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2643
Lines: 68

Thomas Gleixner wrote:
> On Fri, 2005-01-14 at 00:23 -0800, Andrew Morton wrote:
> 
>>- Added the Linux Trace Toolkit (and hence relayfs).  Mainly because I
>>  haven't yet taken as close a look at LTT as I should have.  Probably neither
>>  have you.
> 
> I have. Maybe you should have. I really don't see a good argument to
> include this code. 

[ Lots of excellent criticisms omitted.]

I don't want to be argumentative, but possibly (to answer your last
question first), there are twofold reasons to put this in -mm:
 - there's no tracing infrastructure in the kernel now (except for
 kprobes - which provides hooks for creating tracepoints dynamically,
 but not 1) supporting infrastructure for timestamping, managing event
 data, etc., and 2) a static list of generally useful tracepoints.
 - to generate this discussion.

> 
> I did a short test on a 300MHz PIII box and the maximum time spent in
> the log path (interrupts disabled during measurement) is about 30us.
> Extrapolated to a 74MHz ARM SoC it will sum up to ~ 90-120us, what makes
> it purely useless. 

I've used it for various tasks, and I know others who have.  I wouldn't
recommend it in its present form for deep scheduling tweaks or debugging
kernel race conditions (which it is more likely to mask than
it is to find), but inapplicability there hardly makes it worthless for
other things.

> 
> Summary:
> 
> 1. The code is not doing what it claims to do.
I'm guessing the sense of this is in the micro-claims which are implied
(e.g. runs lockless and therefore avoids cache thrashing), rather than
the high-level claim of providing useful information in some situations.
It clearly does the latter.  At least is has for me.

> 2. The code adds unnecessary overhead
I agree it could be improved.  The threshold for "unnecessary" varies
by task.

> 3. It's not useful for low speed systems.
I've used it on low speed systems.

> Question:
> Why is the code included ?	
See above.

By the way, don't think that your comments are not appreciated.
I'm not particularly glued to any specific part of the implementation.
I'm excited to see tracing discussed here, if only to avoid
duplicate efforts and point out danger areas, for multiple tracing
projects that I am aware of.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/