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]
Message-ID: <20060915220345.GC12789@elte.hu>
Date:	Sat, 16 Sep 2006 00:03:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Andrew Morton <akpm@...l.org>, tglx@...utronix.de,
	karim@...rsys.com, Paul Mundt <lethal@...ux-sh.org>,
	Jes Sorensen <jes@....com>, linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.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


* Jose R. Santos <jrs@...ibm.com> wrote:

> [...]  While it is true that static probes will provide less overhead 
> compared to dynamic probes, [...]

that is not true at all. Yes, an INT3 based kprobe might be expensive if 
+0.5 usecs per tracepoint (on a 1GHz CPU) is an issue to you - but that 
is "only" an implementation detail, not a conceptual property. 
Especially considering that help (djprobes) is on the way. And in the 
future, as more and more code gets generated (and regenerated) on the 
fly, dynamic probes will be _faster_ than static probes - plainly 
because they adapt better to the environment they plug into.

so there's basically nothing to balance. My point is that dynamic probes 
have won or will win on every front, and we shouldnt tie us down with 
static tracers. 5 years ago with no kprobes, had someone submitted a 
clean static tracer patchset, we could probably not have resisted it (i 
though probably would have resisted it on the grounds of maintainance 
overhead) and would have added it because tracing makes sense in 
general. But today there's just no reason to add static tracers anymore.

NOTE: i still accept the temporary (or non-temporary) introduction of 
static markers, to help dynamic tracing. But my expectation is that 
these markers will be less intrusive than static tracepoints, and a lot 
more flexible.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ