From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Martin Bligh <mbligh@google.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
prasanna@in.ibm.com, Andrew Morton <akpm@osdl.org>,
Paul Mundt <lethal@linux-sh.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Jes Sorensen <jes@sgi.com>, Tom Zanussi <zanussi@us.ibm.com>,
Richard J Moore <richardj_moore@uk.ibm.com>,
Michel Dagenais <michel.dagenais@polymtl.ca>,
Christoph Hellwig <hch@infradead.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
William Cohen <wcohen@redhat.com>,
ltt-dev@shafik.org, systemtap@sources.redhat.com,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers 0.5 for Linux 2.6.17 (with probe management)
Date: Thu, 21 Sep 2006 17:42:48 -0400 [thread overview]
Message-ID: <20060921214248.GA10097@Krystal> (raw)
In-Reply-To: <20060921160656.GA24774@elte.hu>
* Ingo Molnar (mingo@elte.hu) wrote:
> "As an example, LTTng traces the page fault handler, when kprobes just
> can't instrument it."
>
> but tracing a raw pagefault at the arch level is a bad idea anyway, we
> want to trace __handle_mm_fault(). That way you can avoid having to
> modify every architecture's pagefault handler ...
>
Then you lose the ability to trace in-kernel minor page faults.
> but the other points remained unanswered as far as i can see.
>
Hi Ingo,
I clearly expressed my position in the previous emails, so did you. You argued
about a use of tracing that is not relevant to my vision of reality, which is :
- Embedded systems developers won't want a breakpoint-based probe
- High performance computing users won't want a breakpoint-based probe
- djprobe is far away from being in an acceptable state on architectures with
very inconvenient erratas (x86).
- kprobe and djprobe cannot access local variables in every cases
For those reasons, I prefer a jump-over-call approach which lets gcc give us the
local variables. No need of DWARF or SystemTAP macro Kung Fu. Just C and a
loadable module.
By no means is it a replacement for a completely dynamic breakpoint-based
instrumentation mechanism. I really think that both mechanism should coexist.
This is my position : I let the distribution/user decide what is appropriate for
their use. My goal is to provide them a flexible mechanism that takes the
multiple variety of uses in account without performance impact if they are not
willing to pay it to benefit from tracing.
With all due respect, yes, there are Linux users different from the typical
Redhat client. If your vision is still limited to this scope after a 500
emails debate, I am afraid that there is very little I can do about it in
one more.
Mathieu
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2006-09-21 21:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-21 16:00 [PATCH] Linux Kernel Markers 0.5 for Linux 2.6.17 (with probe management) Mathieu Desnoyers
2006-09-21 16:06 ` Ingo Molnar
2006-09-21 21:42 ` Mathieu Desnoyers [this message]
2006-09-21 21:49 ` Mathieu Desnoyers
2006-09-22 6:29 ` Karim Yaghmour
2006-09-22 6:49 ` Ingo Molnar
2006-09-22 14:03 ` Mathieu Desnoyers
2006-09-22 16:53 ` Ingo Molnar
2006-09-22 17:11 ` Mathieu Desnoyers
2006-09-22 17:12 ` Ingo Molnar
2006-09-22 17:28 ` Mathieu Desnoyers
2006-09-22 7:07 ` Ingo Molnar
2006-09-22 8:14 ` Karim Yaghmour
2006-09-22 15:08 ` Mathieu Desnoyers
2006-09-22 16:24 ` Karim Yaghmour
2006-09-22 16:13 ` Mathieu Desnoyers
2006-09-22 17:03 ` Karim Yaghmour
2006-09-22 18:06 ` Mathieu Desnoyers
2006-09-22 19:24 ` Karim Yaghmour
2006-09-22 16:45 ` Ingo Molnar
2006-09-22 14:31 ` Christoph Hellwig
2006-09-23 16:51 ` Mathieu Desnoyers
2006-09-21 17:56 ` Frank Ch. Eigler
2006-09-21 18:50 ` Ingo Molnar
2006-09-21 19:54 ` Jeremy Fitzhardinge
2006-09-25 17:45 ` Frank Ch. Eigler
2006-09-21 20:59 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060921214248.GA10097@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=fche@redhat.com \
--cc=gregkh@suse.de \
--cc=hch@infradead.org \
--cc=jes@sgi.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mbligh@google.com \
--cc=michel.dagenais@polymtl.ca \
--cc=mingo@elte.hu \
--cc=prasanna@in.ibm.com \
--cc=richardj_moore@uk.ibm.com \
--cc=systemtap@sources.redhat.com \
--cc=tglx@linutronix.de \
--cc=wcohen@redhat.com \
--cc=zanussi@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox