This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] markers-linker-generic
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Andrew Morton <akpm at linux-foundation dot org>
- Cc: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>, linux-kernel at vger dot kernel dot org, Russell King <rmk at arm dot linux dot org dot uk>, systemtap at sources dot redhat dot com
- Date: 11 Apr 2007 18:58:50 -0400
- Subject: Re: [PATCH] markers-linker-generic
- References: <20070410223658.GC7092@Krystal> <20070411074414.GC3752@flint.arm.linux.org.uk> <20070411175110.GA30879@Krystal> <20070411110240.537ee25d.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> [...] I am told that the systemtap developers plan to (or are)
> using this infrastructure.
Indeed.
> If correct: what is their reason for preferring it over kprobes?
> [...]
It's not a preference - it's more of a supplement. It's helpful when
some combination of such factors exists:
- kprobe int3-fault dispatching overhead orders of magnitude too high
- fault dispatching not permissible in some areas
- local context variables not easily retrievable via dwarf information
- dwarf information not available at all
- costs of permanently placed but passive marker acceptable
>From systemtap's point of view, instrumentation hooked to markers,
kprobes, and other facilities like timers, coexist just fine. A
greater number of probe-able event sources makes for a richer tool.
- FChE