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
| ||
|
Date: Sat, 16 Sep 2006 10:23:10 +0200 From: Ingo Molnar <mingo@...e.hu> To: Roman Zippel <zippel@...ux-m68k.org> Cc: Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com, Andrew Morton <akpm@...l.org>, Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>, Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>, 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 * Roman Zippel <zippel@...ux-m68k.org> wrote: > > > > > > - a marker for dynamic tracing has lower performance impact ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > than a static tracepoint, on systems that are not being ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > traced. (but which have the tracing infrastructure enabled ^^^^^^ > > > > > > otherwise) > > > > > > > > > > Anyone using static tracing intents to use, which makes this point > > > > > moot. > > > > > > > > that's not at all true, on multiple grounds: > > > > > > > > Firstly, many people use distro kernels. A Linux distribution > > > > typically wants to offer as few kernel rpms as possible (one per > > > > arch to be precise), but it also wants to offer as many features > > > > as possible. So if there was a static tracer in there, a distro > > > > would enable it - but 99.9% of the users would never use it - still > > > > they would see the overhead. Hence the user would have it enabled, > > > > but does not intend to use it - which contradicts your statement. > > > > > > So if dynamic tracing is available use it, as distributions > > > already do. OTOH the barrier to use static tracing is drastically > > > different whether the user has to deal with external patches or > > > whether it's a simple kernel option. Again, static tracing doesn't > > > exclude the possibility of dynamic tracing, that's something you > > > constantly omit and thus make it sound like both options were > > > mutually exlusive. > > > > how does this reply to my point that: "a marker for dynamic tracing has > > lower performance impact than a static tracepoint, on systems that are > > not being traced", which point you claimed moot? > > Because it's pretty much an implementation issue. [...] No, that's my point, it's not an "implementational issue" of static tracers, the overhead of markups for static tracers is: _inherent to their concept of being compile-time and static_ ok? > [...] The point is about adding markers at all, it's about the choice > being able to use static tracers in the first place. [...] your characterization of "the point" is at odds with the specific point that we are discussing - see the underlined sentence above, right at the top of the quotes: > > > > > > - a marker for dynamic tracing has lower performance impact > > > > > > than a static tracepoint, on systems that are not being > > > > > > traced. (but which have the tracing infrastructure enabled Please either concede the point or dispute it, before shifting to new grounds. Thanks, 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