LKML Archive on
 help / color / Atom feed
From: Mathieu Desnoyers <>
To: Steven Rostedt <>
Cc: Thomas Gleixner <>,
	LKML <>,
	Jiang Liu <>,, Linus Torvalds <>,
	Andrew Morton <>,
	Bjorn Helgaas <>,
	Tony Luck <>, Borislav Petkov <>,
	Joerg Roedel <>,
	Marc Zyngier <>,
	Yinghai Lu <>,
	Alex Williamson <>,
	Frederic Weisbecker <>
Subject: Re: Status of tip/x86/apic
Date: Fri, 2 Jan 2015 17:29:42 +0000 (UTC)
Message-ID: <> (raw)
In-Reply-To: <20141215105201.16110c6d@gandalf.local.home>

----- Original Message -----
> From: "Steven Rostedt" <>
> To: "Thomas Gleixner" <>
> Cc: "LKML" <>, "Jiang Liu" <>,, "Linus Torvalds"
> <>, "Andrew Morton" <>, "Bjorn Helgaas" <>,
> "Tony Luck" <>, "Borislav Petkov" <>, "Joerg Roedel" <>, "Marc
> Zyngier" <>, "Yinghai Lu" <>, "Alex Williamson" <>,
> "Mathieu Desnoyers" <>, "Frederic Weisbecker" <>
> Sent: Monday, December 15, 2014 10:52:01 AM
> Subject: Re: Status of tip/x86/apic
> >       
> >       I think the above can be solved, so we need to agree on a proper
> >       set of tracepoints. I came up with the following list:
> > 
> >       - trace_irqdomain_create(domain->id, domain->name, ...)
> Is that suppose to be a variable number of args? Tracepoints do not
> support a variable length number of args passed in. I guess we could
> add that, but it wont be for this merge window.
> I've added Mathieu and Frederic to the Cc list here.

Hi Steven,

Let's wait and see if it's really required first.

FWIW, at the user-space level in LTTng-UST, we have two distinct ways to
do static instrumentation:

  * tracepoint(): similar to those within the Linux kernel, except that the
                  tracepoint is wrapped in a define, so rather than calling:
                    trace_foo(arg1, arg2);
                  users call:
                    tracepoint(foo, arg1, arg2);

                  Which allows skipping over evaluation of "arg1" and "arg2"
                  even if they have side-effects when the tracepoint is disabled.

  * tracef(): I also added a "tracef()" macro, provides a programmer interface
              very similar to printf(), but prints the pretty-printed into the
              trace buffers. It can be enabled dynamically similarly to tracepoints,
              but does not have per-site event names attached. They are either all
              enabled or disabled, and meant mainly for adding temporary debugging
              trace statements.

So far, the feedback I got from end users seemed to split static
instrumentation use-cases in two major categories:

1) Instrumentation added into the code base, well structured (tracepoints),
   meant to be deployed with the application for in-production use.
   They need to be low-overhead,
2) Very quick (and dirty) instrumentation, meant for one-off use while
   in development. IOW, a replacement to printf(), with which people are
   already familiar. Low-overhead still matters, but not as much as it does
   for (1).

This is why we only implemented var arg support in tracef() so far.

> If we do support this (and if it is needed) we could make it use the
> bprintf() infrastructure. It already supports just saving a format and
> args directly to the the buffer, and a way to print them again.

Happy new year :)



Mathieu Desnoyers
EfficiOS Inc.

      reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-12 20:35 Thomas Gleixner
2014-12-12 21:45 ` Borislav Petkov
2014-12-12 23:02 ` Linus Torvalds
2014-12-12 23:14 ` Steven Rostedt
2014-12-13  5:48   ` [RFC PATCH 0/2] tracing: The Grinch who stole the stealing of Christmas Steven Rostedt
2014-12-13  5:49     ` [RFC PATCH 1/2] tracing: Move enabling tracepoints to just after mm_init() Steven Rostedt
2014-12-13  5:50     ` [RFC PATCH 2/2] tracing: Add tracepoint_printk cmdline Steven Rostedt
2014-12-13 10:59       ` Borislav Petkov
2014-12-13 13:18         ` Steven Rostedt
2014-12-13 13:33           ` Borislav Petkov
2014-12-14 10:57 ` Status of tip/x86/apic Jiang Liu
2014-12-15 15:52 ` Steven Rostedt
2015-01-02 17:29   ` Mathieu Desnoyers [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone