LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 3/4] Linux Kernel Markers - Documentation
Date: Fri, 17 Aug 2007 11:56:45 -0400	[thread overview]
Message-ID: <20070817155645.GB29458@Krystal> (raw)
In-Reply-To: <y0my7ggldi9.fsf@ton.toronto.redhat.com>

* Frank Ch. Eigler (fche@redhat.com) wrote:
> 
> Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:
> 
> > [...]
> > +A marker placed in your code provides a hook to call a function (probe) that
> > +you can provide at runtime. A marker can be "on" (a probe is connected to it)
> > +or "off" (no probe is attached). When a marker is "off" it has no
> > +effect. [...]
> 
> Add something like, ", except for a (how?) small time/space penalty."
> 

Yup, good idea. I plan to add:

When a marker is "off" it has no effect, except for adding a tiny time
penality (checking a condition for a branch) and space penality (adding
a few bytes for the function call at the end of the instrumented
function and adds a data structure in a separate section). The
immediate values are used to minimize the impact on data cache, encoding
the condition in the instruction stream.

> > +[...]
> > +trace_mark(subsystem_event, "%d %s", someint, somestring);
> > +Where :
> > +- subsystem_event is an identifier unique to your event
> > +    - subsystem is the name of your subsystem.
> > +    - event is the name of the event to mark.
> > +[...]
> 
> It would be useful to clarify that this "subsystem_event" scheme is
> only a suggested naming convention intended to limit collisions.
> 

Sure. Adding:

The naming scheme "subsystem_event" is suggested here as a convention
intended to limit collisions.



> > +Connecting a function (probe) to a marker is done by providing a
> > probe +(function to call) for the specific marker through
> > marker_probe_register() and +can be activated by calling
> > marker_arm().
> 
> It would help to spell out the nature of the marker namespace.  Is it
> global to the kernel?  Per-module?  Are conflicting "subsystem_event"
> names but different format strings considered separate markers?
> 

What do you think of :

Marker names are global to the kernel: they are considered as being the
same whether they are in the core kernel image or in modules.
Conflicting format strings for markers with the same name will cause the
markers to be detected to have a different format string not to be armed
and will output a printk warning which identifies the inconsistency:

"Format mismatch for probe probe_name (format), marker (format)"



> > + [...] Marker disactivation [...]
> 
> "deactivation"
> 

Thanks for the review,

Mathieu


> - FChE

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2007-08-17 15:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-12 15:10 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-08-12 15:10 ` [patch 1/4] Linux Kernel Markers - Architecture Independent Code Mathieu Desnoyers
2007-08-12 15:10 ` [patch 2/4] Linux Kernel Markers - Add kconfig menus for the marker code Mathieu Desnoyers
2007-08-12 15:10 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-08-12 20:11   ` Frank Ch. Eigler
2007-08-17 15:56     ` Mathieu Desnoyers [this message]
2007-08-12 15:10 ` [patch 4/4] Port of blktrace to the Linux Kernel Markers Mathieu Desnoyers
  -- strict thread matches above, loose matches on Subject: below --
2007-09-18 21:13 [patch 0/4] Linux Kernel Markers for 2.6.23-rc6-mm1 Mathieu Desnoyers
2007-09-18 21:13 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-09-18 23:22   ` Randy Dunlap
2007-09-19 11:18     ` Mathieu Desnoyers
2007-09-17 18:46 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-09-17 18:46 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-08-27 16:05 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-08-27 16:05 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-08-20 20:27 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-08-20 20:27 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-08-28 20:53   ` Christoph Hellwig
2007-08-28 21:24     ` Mathieu Desnoyers
2007-07-14  1:29 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-07-14  1:29 ` [patch 3/4] Linux Kernel Markers - Documentation Mathieu Desnoyers
2007-07-03 17:08 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-07-03 17:08 ` [patch 3/4] Linux Kernel Markers - Documentation 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=20070817155645.GB29458@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@linux-foundation.org \
    --cc=fche@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [patch 3/4] Linux Kernel Markers - Documentation' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).