public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	prasad@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	tglx@linutronix.de, mingo@elte.hu,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC PATCH 1/2] Marker probes in futex.c
Date: Thu, 17 Apr 2008 15:19:10 -0400	[thread overview]
Message-ID: <20080417191910.GI28235@redhat.com> (raw)
In-Reply-To: <1208361084.6395.80.camel@twins>

Hi -

On Wed, Apr 16, 2008 at 05:51:24PM +0200, Peter Zijlstra wrote:
> [...]
> > > > > What is wrong with a few simple hooks like:
> > > > >   trace_futex_wait(uaddr, fshares, val, abs_time, bitset);
> > > > > and then deal with that.
> [...]
> > Yes, but then you would have to create new code for each event you want
> > to trace. In the end, it would increase the icache footprint
> > considerably and would also make addition of new events cumbersome.
> > [...]

That, plus the new hand-written function (trace_futex_wait) would
still need to manage the packaging of the arguments for consumption by
separately compiled pieces.  It is desirable not to require such
hand-written functions to *also* be declared in headers for these
event consumers to compile against.


> So I'm not sure what adding all these character strings buy you.

The main thing is type checking by engaging gcc's printf format
checking logic.  In my original markers proposal, the types were
encoded into the function name, sort of as in C++:

  trace_mark_nnnnn(futex_wake_called, uaddr, fshares, val, abs_time, bitset);

where each "n" stands for some integral value, and could be chosen
amongst a small number of other types (say -- "s": char* string, "p":
void*, "l":64-bit long).  Then, type checking could be done by the
core compiler for both event producers and consumers.  One downside
was that the trace_mark_* permutations themselves would have to be
generated by some shell/perl script [1], and some deemed this probably
unacceptable.  I'm still not sure...

[1] some systemtap archaeology:
http://sourceware.org/git/?p=systemtap.git;a=commit;h=b171146c8e8d4fa749b8829c47750750dc19f11c


> >+       trace_mark(futex_wake_called, "uaddr:%p fshared:%p nr_wake:%d "
> > +                       "bitset:%d",
> > +                       uaddr, fshared, nr_wake, bitset);
> 
> > +       INIT_FUTEX_DEBUG_PROBE(futex_wake_called,
> > +                       "uaddr:%p fshared:%p nr_wake:%d bitset:%d"),
> 
> Why the need to duplicate it; that's utter madness.

This second instance is optional and is used as a consistency check
for the event consumer to hook up exactly to the intended producer.
The string could be empty.


- FChE

  reply	other threads:[~2008-04-17 19:50 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15 11:50 [RFC PATCH 0/2] Debugging infrastructure for Futexes using Markers K. Prasad
2008-04-15 11:53 ` [RFC PATCH 1/2] Marker probes in futex.c K. Prasad
2008-04-15 11:55   ` [RFC PATCH 2/2] Marker handler for the probes in futex file K. Prasad
2008-04-15 12:02   ` [RFC PATCH 1/2] Marker probes in futex.c Peter Zijlstra
2008-04-15 12:32     ` Mathieu Desnoyers
2008-04-15 12:50       ` Alexey Dobriyan
2008-04-15 16:13         ` K. Prasad
2008-04-15 12:56       ` Peter Zijlstra
2008-04-15 13:17         ` Ingo Molnar
2008-04-15 13:47           ` Mathieu Desnoyers
2008-04-15 14:04             ` Ingo Molnar
2008-04-15 14:21               ` Frank Ch. Eigler
2008-04-15 14:39               ` Mathieu Desnoyers
2008-04-15 16:48             ` Ingo Molnar
2008-04-15 21:38               ` Mathieu Desnoyers
2008-04-16 13:17                 ` Ingo Molnar
2008-04-16 13:46                   ` Arjan van de Ven
2008-04-16 14:00                     ` Mathieu Desnoyers
2008-04-16 14:24                       ` Arjan van de Ven
2008-04-16 14:29                         ` Ingo Molnar
2008-04-16 14:48                         ` Mathieu Desnoyers
2008-04-16 15:32                           ` Arjan van de Ven
2008-04-16 15:39                             ` Mathieu Desnoyers
2008-04-16 20:10                   ` text_poke, vmap and vmalloc on x86_64 Mathieu Desnoyers
2008-04-16 21:22                     ` Mathieu Desnoyers
2008-04-15 13:25         ` [RFC PATCH 1/2] Marker probes in futex.c Mathieu Desnoyers
2008-04-16 15:51           ` Peter Zijlstra
2008-04-17 19:19             ` Frank Ch. Eigler [this message]
2008-04-17 20:16               ` Mathieu Desnoyers
2008-04-19 12:13                 ` K. Prasad
2008-04-19 21:33                   ` Mathieu Desnoyers
2008-04-18  6:56               ` Peter Zijlstra
2008-04-15 15:52     ` K. Prasad
2008-04-16 15:51       ` Peter Zijlstra
2008-04-17 22:02         ` Frank Ch. Eigler
2008-04-18  6:46           ` Peter Zijlstra
2008-04-18 14:29             ` Frank Ch. Eigler
2008-04-19 12:28               ` K. Prasad
2008-04-19 14:52               ` Peter Zijlstra
2008-04-19 18:03                 ` Frank Ch. Eigler
2008-04-19 18:29                   ` Peter Zijlstra
2008-04-19 18:48                     ` Frank Ch. Eigler
2008-04-22 17:50                       ` Nicholas Miell
2008-04-19 14:13             ` Mathieu Desnoyers
2008-04-19 14:56               ` Peter Zijlstra
2008-04-18 10:44     ` Andrew Morton

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=20080417191910.GI28235@redhat.com \
    --to=fche@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    /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