linux-kernel - Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

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: <20060914135548.GA24393@elte.hu>
Date:	Thu, 14 Sep 2006 15:55:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
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

* Roman Zippel <zippel@...ux-m68k.org> 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)

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

 - they can only be added at the source code level

 - modifying them requires a reboot which is not practical in a 
   production environment

 - there can only be a limited set of them, while many problems need 
   finegrained tracepoints tailored to the problem at hand

 - conditional tracepoints are typically either nonexistent or very 
   limited.

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.

enter KProbes+SystemTap. It needs no changes at the source code level at 
all, so no maintainance overhead to generic kernel code. Tracepoints can 
be added and removed while the system is running. Trace actions and 
filters can be added based on a scripting language, so tracing is as 
dynamic as it gets.

(check out http://lwn.net/Articles/198557/ if you have an lwn 
subscription - it's subscriber-only for a few weeks)

	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/