From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: "Frank Ch. Eigler" <fche@redhat.com>
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: Fri, 18 Apr 2008 08:56:07 +0200 [thread overview]
Message-ID: <1208501767.7115.67.camel@twins> (raw)
In-Reply-To: <20080417191910.GI28235@redhat.com>
On Thu, 2008-04-17 at 15:19 -0400, Frank Ch. Eigler wrote:
> 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.
*blink* so all this is so you don't have to put a declarion in a header
file?
How about we put these premanent markers in a header - Mathieu says
there are <200. Surely that's not too much trouble.
Then you can keep this trace_mark() (perhaps trace_printf() is a better
name) around for the ad-hoc debug hacks.
> > 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.
So instead of writing normal C code and placing a declarion in a header,
you've come up with a scheme that needs to duplicate a text string to
check integrity. Sounds like a real good way to confuse people.
next prev parent reply other threads:[~2008-04-18 6:56 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
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 [this message]
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=1208501767.7115.67.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=fche@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.