All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH 02/11] tracing: Introduce TRACE_EVENT_INJECT
Date: Wed, 10 Feb 2010 11:04:43 +0100	[thread overview]
Message-ID: <20100210100440.GA5035@nowhere> (raw)
In-Reply-To: <1265462370.4561.12179.camel@frodo>

On Sat, Feb 06, 2010 at 08:19:30AM -0500, Steven Rostedt wrote:
> On Sat, 2010-02-06 at 13:20 +0100, Frederic Weisbecker wrote:
> 
> > I agree with you that creating a new trace event macro is a bit
> > insane. ftrace.h is already a nightmare. I just thought that
> > having the injector set inside the same macro that the synchronous
> > event is defined helped to make it clear about its nature: that
> > it needs a secondary async catch up thing.
> > 
> > But a register_event_injector thing will work too, we probably
> > better want that, given the maintainance pain otherwise.
> 
> We can add a register_event_injector later. For now, why not just add
> the TRACE_EVENT() and then hook to it in perf using the normal
> tracepoint mechanism.
> 
> You could add some macro around the trace_init_lock_class() call that
> would facilitate finding all the locks you need. This would probably be
> a bit more straight forward than to overload TRACE_EVENT() again.



I'm not sure what you mean by that.


 
> > 
> > I really would like to make something useful for everyone, could
> > you tell me more about johill needs?
> 
> Well, basically he needed a way to cause polling to happen using an
> event. From what I understood, the polling called the trace point. Just
> enabling the trace point did nothing because the polling did not take
> place. I thought about ways to enable this command when the trace point
> was enabled. But in the end, it was specific to a driver and another
> debugfs file seemed a better fit to initiate it.


Ok, thanks.


  reply	other threads:[~2010-02-10 10:04 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03  9:14 [RFC GIT PULL] perf/trace/lock optimization/scalability improvements Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 01/11] tracing: Add lock_class_init event Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 02/11] tracing: Introduce TRACE_EVENT_INJECT Frederic Weisbecker
2010-02-05 14:08   ` Steven Rostedt
2010-02-05 14:47   ` Steven Rostedt
2010-02-05 14:53     ` Peter Zijlstra
2010-02-05 15:07       ` Steven Rostedt
2010-02-06 12:20         ` Frederic Weisbecker
2010-02-06 13:19           ` Steven Rostedt
2010-02-10 10:04             ` Frederic Weisbecker [this message]
2010-02-10 14:05               ` Steven Rostedt
2010-02-11 18:57                 ` Frederic Weisbecker
2010-02-11 19:23                   ` Steven Rostedt
2010-02-03  9:14 ` [PATCH 03/11] tracing: Inject lock_class_init events on registration Frederic Weisbecker
2010-02-05 14:13   ` Steven Rostedt
2010-02-05 14:30     ` Peter Zijlstra
2010-02-05 14:44       ` Steven Rostedt
2010-02-03  9:14 ` [PATCH 04/11] tracing: Add lock class id in lock_acquire event Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 05/11] perf: New PERF_EVENT_IOC_INJECT ioctl Frederic Weisbecker
2010-02-03  9:19   ` Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 06/11] perf: Handle injection ioctl with trace events Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 07/11] perf: Handle injection iotcl for tracepoints from perf record Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 08/11] perf/lock: Add support for lock_class_init events Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 09/11] tracing: Remove the lock name from most lock events Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 10/11] tracing/perf: Fix lock events recursions in the fast path Frederic Weisbecker
2010-02-04 15:47   ` Paul E. McKenney
2010-02-05  2:38     ` Lai Jiangshan
2010-02-05  9:45       ` Peter Zijlstra
2010-02-05  9:50         ` Peter Zijlstra
2010-02-05 10:49           ` Ingo Molnar
2010-02-05 12:10             ` Peter Zijlstra
2010-02-05 12:12               ` Peter Zijlstra
2010-02-05 13:01                 ` Peter Zijlstra
2010-02-06 11:12                   ` Frederic Weisbecker
2010-02-06 11:24                     ` Peter Zijlstra
2010-02-06 11:40                       ` Frederic Weisbecker
2010-02-06 14:17                         ` Peter Zijlstra
2010-02-06 16:10                           ` Frederic Weisbecker
2010-02-07  9:45                             ` Peter Zijlstra
2010-02-10 10:17                               ` Frederic Weisbecker
2010-02-28 22:24                   ` Frederic Weisbecker
2010-02-03  9:14 ` [PATCH 11/11] perf lock: Drop the buffers multiplexing dependency Frederic Weisbecker
2010-02-03 10:25 ` [RFC GIT PULL] perf/trace/lock optimization/scalability improvements Jens Axboe
2010-02-03 20:50   ` Frederic Weisbecker
2010-02-03 21:21     ` Jens Axboe
2010-02-03 22:13       ` Frederic Weisbecker
2010-02-04 19:40     ` Jens Axboe
2010-02-06 10:37       ` Frederic Weisbecker
2010-02-03 10:26 ` Ingo Molnar
2010-02-03 21:26   ` Frederic Weisbecker
2010-02-03 10:33 ` Peter Zijlstra
2010-02-03 22:07   ` Frederic Weisbecker
2010-02-04  6:33     ` Ingo Molnar
2010-02-07 17:10     ` Peter Zijlstra
2010-02-10 10:49       ` Frederic Weisbecker

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=20100210100440.GA5035@nowhere \
    --to=fweisbec@gmail.com \
    --cc=acme@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=mitake@dcl.info.waseda.ac.jp \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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.