LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Richard J Moore <richardj_moore@uk.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, ltt-dev@shafik.org,
	"Martin J. Bligh" <mbligh@mbligh.org>,
	Ingo Molnar <mingo@redhat.com>,
	Douglas Niehaus <niehaus@eecs.ku.edu>,
	systemtap@sources.redhat.com,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/4] Linux Kernel Markers
Date: Sat, 13 Jan 2007 00:45:34 -0500	[thread overview]
Message-ID: <20070113054534.GA27017@Krystal> (raw)
In-Reply-To: <OFAB3D8A6C.1643F2D3-ON80257262.000581E4-80257262.00088F04@uk.ibm.com>

Hi Richard,

* Richard J Moore (richardj_moore@uk.ibm.com) wrote:
> 
> 
> Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote on 20/12/2006
> 23:52:16:
> 
> > Hi,
> >
> > You will find, in the following posts, the latest revision of the Linux
> Kernel
> > Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of
> this
> > kind of mechanism, it could be nice to consider it for mainstream
> inclusion.
> >
> > The following patches apply on 2.6.20-rc1-git7.
> >
> > Signed-off-by : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> 
> Mathiue, FWIW I like this idea. A few years ago I implemented something
> similar, but that had no explicit clients. Consequently I made my hooks
> code more generalized than is needed in practice. I do remember that Karim
> reworked the LTT instrumentation to use hooks and it worked fine.
> 

Yes, I think some features you implemented in GKHI, like chained calls to
multiple probes, should be implemented in a "probe management module" which
would be built on top of the marker infrastructure. One of my goal is to
concentrate on having the core right so that, afterward, building on top of it
will be easy.

> You've got the same optimizations for x86 by modifying an instruction's
> immediate operand and thus avoiding a d-cache hit. The only real caveat is
> the need to avoid the unsynchronised cross modification erratum. Which
> means that all processors will need to issue a serializing operation before
> executing a Marker whose state is changed. How is that handled?
> 

Good catch. I thought that modifying only 1 byte would spare us from this
errata, but looking at it in detail tells me than it's not the case.

I see three different ways to address the problem :
1 - Adding some synchronization code in the marker and using
    synchronize_sched().
2 - Using an IPI to make other CPUs busy loop while we change the code and then
    execute a serializing instruction (iret, cpuid...).
3 - First write an int3 instead of the instruction's first byte. The handler
    would do the following :
    int3_handler :
      single-step the original instruction.
      iret

    Secondly, we call an IPI that does a smp_processor_id() on each CPU and
    wait for them to complete. It will make sure we execute a synchronizing
    instruction on every CPU even if we do not execute the trap handler.

    Then, we write the new 2 bytes instruction atomically instead of the int3
    and immediate value.


I exclude (1) because of the performance impact, (2) because it does not deal
with NMIs. It leaves (3). Does it make sense ?


> One additional thing we did, which might be useful at some future point,
> was adding a /proc interface. We reflected the current instrumentation
> though /proc and gave the status of each hook. We even talked about being
> able to enable or disabled instrumentation by writing to /proc but I don't
> think we ever implemented this.
> 

Adding a /proc output to list the active probes and their
callback will be tribial to add to the markers. I think the probe management
module should have its /proc file too to list the chains of connected handlers
once we get there.

> It's high time we settled the issue of instrumentation. It gets my vote,
> 
> Good luck!
> 
> Richard
> 

Thanks,

Mathieu

> - -
> Richard J Moore
> IBM Linux Technology Centre
> 

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

  reply	other threads:[~2007-01-13  5:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-20 23:52 Mathieu Desnoyers
2006-12-20 23:57 ` [PATCH 1/4] Linux Kernel Markers : Architecture agnostic code Mathieu Desnoyers
2006-12-20 23:59 ` [PATCH 2/4] Linux Kernel Markers : kconfig menus Mathieu Desnoyers
2006-12-21  0:00 ` [PATCH 3/4] Linux Kernel Markers : i386 optimisation Mathieu Desnoyers
2006-12-21  0:01 ` [PATCH 4/4] Linux Kernel Markers : powerpc optimisation Mathieu Desnoyers
2007-01-13  1:33 ` [PATCH 0/4] Linux Kernel Markers Richard J Moore
2007-01-13  5:45   ` Mathieu Desnoyers [this message]
2007-01-16 17:41     ` [PATCH 0/4 update] Linux Kernel Markers - i386 : pIII erratum 49 : XMC Mathieu Desnoyers
2007-01-16 18:35       ` Frank Ch. Eigler
2007-01-16 21:27       ` [PATCH 0/4 update] kprobes and traps Mathieu Desnoyers
2007-01-17 12:25         ` S. P. Prasanna
2007-01-16 17:56   ` [PATCH 1/2] lockdep missing barrier() Mathieu Desnoyers
2007-01-24  4:26     ` Andrew Morton
2007-01-24 16:51       ` Mathieu Desnoyers
2007-01-24 17:24         ` [PATCH] order of lockdep off/on in vprintk() should be changed Mathieu Desnoyers
2007-01-24 17:55           ` [PATCH] minimize lockdep_on/off side-effect Mathieu Desnoyers
2007-01-16 17:56   ` [PATCH 2/2] lockdep reentrancy Mathieu Desnoyers
2007-01-24  4:29     ` Andrew Morton
2007-01-24 16:55       ` Mathieu Desnoyers
2007-07-03 17:08 [patch 0/4] Linux Kernel Markers Mathieu Desnoyers
2007-07-03 18:01 ` Mathieu Desnoyers
2007-07-05  2:00 ` Frank Ch. Eigler
2007-07-11 21:43   ` Mathieu Desnoyers
2007-07-14  1:29 Mathieu Desnoyers
2007-08-12 15:10 Mathieu Desnoyers
2007-08-20 20:27 Mathieu Desnoyers
2007-08-27 16:05 Mathieu Desnoyers
2007-08-30 17:12 ` Christoph Hellwig
2007-08-31  1:16   ` Andrew Morton
2007-09-17 18: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=20070113054534.GA27017@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=akpm@osdl.org \
    --cc=gregkh@suse.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=mbligh@mbligh.org \
    --cc=mingo@redhat.com \
    --cc=niehaus@eecs.ku.edu \
    --cc=richardj_moore@uk.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=tglx@linutronix.de \
    --subject='Re: [PATCH 0/4] Linux Kernel Markers' \
    /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).