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:	Thu, 14 Sep 2006 16:33:46 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	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

Hi,

On Thu, 14 Sep 2006, Ingo Molnar wrote:

> > On Thu, 14 Sep 2006, Ingo Molnar wrote:
> > 
> > > i have one very fundamental question: why should we do this 
> > > source-intrusive method of adding tracepoints instead of the dynamic, 
> > > unintrusive (and thus zero-overhead) KProbes+SystemTap method?
> > 
> > Could you define "zero-overhead"?
> 
> zero overhead when not used: not a single instruction added to the 
> kernel codepath that is to be traced, anywhere. (which will be the case 
> on 99% of the systems)

Using alternatives this could be near zero as well and it will likely 
have less overhead when it's actually used.

> > Actual implementation aside having a core number of tracepoints is far 
> > more portable than KProbes.
> 
> the key point is that we want _zero_ "static tracepoints". Firstly, 
> static tracepoints are fundamentally limited:

BTW I don't mind KProbes as an option, but I have huge problem with making 
it the only option.

> But besides the usability problems, the most important problem is that 
> static tracepoints add a _constant maintainance overhead_ to the kernel. 
> I'm talking from first hand experience: i wrote 'iotrace' (a static 
> tracer) in 1996 and have maintained it for many years, and even today 
> i'm maintaining a handful of tracepoints in the -rt kernel. I _dont_ 
> want static tracepoints in the mainline kernel.

Even dynamic tracepoints have a maintainance overhead and I doubt there is 
much difference. The big problem is having to maintain them outside the 
mainline kernel, that's why it's so important to get them into the 
mainline kernel.
You didn't address my main issue at all - kprobes is only available for a 
few archs...

bye, Roman
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ