linux-kernel - Re: [RFC patch 00/41] LTTng 0.105 core for Linux 2.6.27-rc9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Mar 2009 19:32:31 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	ltt-dev@...ts.casi.polymtl.ca,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Pekka Paalanen <pq@....fi>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Martin Bligh <mbligh@...gle.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Jason Baron <jbaron@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	mrubin@...gle.com, md@...gle.com
Subject: Re: [RFC patch 00/41] LTTng 0.105 core for Linux 2.6.27-rc9


* Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:

> > Let me give you a few examples of existing areas of overlap:
> > 
> > > The corresponding git tree contains also the trace clock 
> > > patches and the lttng instrumentation. The trace clock is 
> > > required to use the tracer, but it can be used without the 
> > > instrumentation : there is already a kprobes and userspace 
> > > event support included in this patchset.
> > 
> > The latest tracing tree includes 
> > kernel/tracing/trace_clock.c which offers three trace clock 
> > variants, with different performance/precision tradeoffs:
> > 
> >  trace_clock_local()   [ for pure CPU-local tracers with no idle 
> >                          events. This is the fastest but least 
> >                          coherent tracing clock. ]
> > 
> >  trace_clock()         [ intermediate, scalable clock with
> >                          usable but imprecise global coherency. ]
> > 
> >  trace_clock_global()  [ globally serialized, coherent clock. 
> >                          It is the slowest but most accurate variant. ]
> > 
> > Tracing plugins can pick their choice. (This is relatively new 
> > code but you get the idea.)
> > 
> 
> Hehe this reminds me of the trace clock thread I started a few 
> months ago on LKML. So you guys took over that work ? Nice :) 
> Is it based on the trace-clock patches I proposed back then ? 
> Ah, no. Well I guess we'll have to discuss this too. I agree 
> on the trace_clock_local/trace_clock/trace_clock_global 
> interface, it looks nice. The underlying implementation will 
> have to be discussed though.

Beware: i found the assembly trace_clock() stuff you did back 
then rather ugly ;-) I dont think there's any easy solutions 
here, so i went for this palette of clocks.

> > This approach works for all your other patches as well. A 
> > direct, constructive comparison and active work on unifying 
> > them is required.
> 
> Yes, let's try to do it. Maybe it's better to start a new 
> thread with less CCs for this type of work ?

Yeah. More finegrained steps are really needed.

The least controversial bits would be the many tracepoints you 
identified in LTTng as interesting. Mind sending them separately 
so that we can make some progress?

In the latest tracing code all tracepoints will show up 
automatically under /debug/tracing/events/ and can be used by 
user-space tools.

	Ingo
--
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/