public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@redhat.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Douglas Niehaus <niehaus@eecs.ku.edu>,
	Tom Zanussi <zanussi@us.ibm.com>,
	Paul Mundt <lethal@linux-sh.org>, Jes Sorensen <jes@sgi.com>,
	Richard J Moore <richardj_moore@uk.ibm.com>,
	William Cohen <wcohen@redhat.com>,
	"Martin J. Bligh" <mbligh@mbligh.org>,
	Michel Dagenais <michel.dagenais@polymtl.ca>,
	systemtap@sources.redhat.com, ltt-dev@shafik.org
Subject: Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
Date: Tue, 19 Sep 2006 16:28:02 -0400	[thread overview]
Message-ID: <20060919202802.GB552@Krystal> (raw)
In-Reply-To: <20060919194515.GB18646@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

* Frank Ch. Eigler (fche@redhat.com) wrote:
> Hi -
> 
> On Tue, Sep 19, 2006 at 03:36:24PM -0400, Mathieu Desnoyers wrote:
> > [...]
> > > If you don't allow yourself to presume on-the-fly function
> > > recompilation, then these markers would need to be made run-time
> > > rather than compile-time configurable.  That is, not like this:
> > > [...]
> 
> > By making them run-time configurable, I don't see any whay not to bloat the
> > kernel. How can be embed calls to printk+function+kprobe+djprobe without
> > having some kind of performance impact ?
> 
> In order to have what we appear to need, we cannot avoid having some
> impact.  (Even NOPs have impact.)
> 

I am all for giving this decision to the end-user or the distribution which will
configure the kernel. There is no "perfect" or "for all" solution that I am
aware of.

* Users debugging servers will more likely want the kprobe or jprobe option.
* Users interested in high performance tracing will want fprobe and/or jprobe.
* Users interested in embedded systems will want to avoid tools outside the
  kernel that rely on module loading : their kernel often not even support
  modules. -> fprobe

> Suppose that mbligh's clever but speculative idea has some nasty flaw,
> once someone tried to reduce it to code.  Do you see that markers
> along the lines you've posted would be unsatisfactory?  With that in
> mind, is there point adding such markers now?
> 

M. Bligh's idea is an interesting use of fprobes through modules that could make
dynamic tracing more effective for accessing local variables. It does not
change anything to the various needs of the above-mentioned class of users,
except that it may make life of high performance and server users easier. With
or without his idea, the goal of this marker mechanism is to meet all those
user's different needs.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-09-19 20:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-19 18:34 [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17 Mathieu Desnoyers
2006-09-19  8:39 ` S. P. Prasanna
2006-09-19 20:05   ` Mathieu Desnoyers
2006-09-19 18:51 ` Randy.Dunlap
2006-09-19 19:13   ` Mathieu Desnoyers
2006-09-19 19:23 ` Frank Ch. Eigler
2006-09-19 19:36   ` Mathieu Desnoyers
2006-09-19 19:45     ` Frank Ch. Eigler
2006-09-19 20:28       ` Mathieu Desnoyers [this message]
2006-09-19 21:07         ` Frank Ch. Eigler
2006-09-19 22:11           ` Karim Yaghmour
2006-09-20 13:20             ` Frank Ch. Eigler
2006-09-20 13:38               ` Mathieu Desnoyers
2006-09-20 14:57                 ` Mathieu Desnoyers
2006-09-20 15:53                   ` Frank Ch. Eigler
2006-09-20 16:37                     ` Mathieu Desnoyers
2006-09-20 17:14                     ` Mathieu Desnoyers
2006-09-20 13:46               ` 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=20060919202802.GB552@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@osdl.org \
    --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=mbligh@mbligh.org \
    --cc=michel.dagenais@polymtl.ca \
    --cc=mingo@redhat.com \
    --cc=niehaus@eecs.ku.edu \
    --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