Message-ID: <450BD4C7.8030000@sgi.com>
Date:	Sat, 16 Sep 2006 12:41:11 +0200
From:	Jes Sorensen <jes@....com>
To:	karim@...rsys.com
Cc:	Ingo Molnar <mingo@...e.hu>, Roman Zippel <zippel@...ux-m68k.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

Karim Yaghmour wrote:
> Jes Sorensen wrote:
>> There very few tracepoints in this category,
> 
> Wow, that's progress.

Karim,

A personal question?, do you feel that being patronising and insulting
is in any way going to put your LTT project in a better light? It
certainly makes it a  lot harder for many of us to take your arguments
serious.

>> the only things you can claim are more or less generic are syscalls,
 >> and tracing syscall handling is tricky.
> 
> If there are implementation issue, I trust an adequate solution can be
> found by using the tested-and-proven method of posting stuff on the
> lkml for review.

And how is this going to solve the case where trace code in the syscall
path has a negative impact on cacheline utilization and alignment, even
when the trace data is not being used?

>> This is grossly over simplifying things and why the whole things doesn't
>> hold water. There is no such thing as 'the place' to put a specific
>> tracepoint.
[snip]
> I do not underestimate the difficulty of selecting such tracepoints.
> This is why I chose not to maintain other people's specific tracepoints.
> I realize this is a tough problem, but I also trust subsystem maintainers
> are smart enough to make the appropriate decision.

So you are back to saying that trace data other people wish to collect
are uninteresting and therefore should just be ignored? If not, what you
are saying there otherwise just backs up the argument that if LTT or
something similar goes into mainline, we will see the amount of
tracepoints grow significantly.

>> You seem to think that it's fine to add instrumentation in the syscall
>> path as an example as long as it's compiled out. Well on some
>> architectures, the syscall path is very sensitive to alignment and there
>> may be restrictions on how large the stub of code is allowed to be, like
>> a few hundred bytes. Just because things work one way on x86, doesn't
>> mean they work like that everywhere.
> 
> If ltt failed to implement such things appropriately, then we apologize.
> That fact doesn't preclude proper implementation in the future, however.

Please read what I wrote above! Touching the syscall path with static
tracepoints is costly and has side effects! The argument that things can
be compiled out is just pointless, end users do not recompile kernels at
random and many of the 'end user' cases where people wish to vizualize
trace data, are running on precompiled vendor kernels. Recompiling the
kernel and rebooting is not an option here!

In fact, the users who wish to trace data in self-compiled kernels are a
tiny subset of the potential userbase for this stuff which is primarily
useful to developers .... which in terms makes your argument about debug
tracepoints irrelevant since you are turning all the tracepoints into
debug tracepoints :)

Jes
-
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