All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Hideo AOKI <haoki@redhat.com>,
	mingo@elte.hu, linux-kernel@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: Kernel marker has no performance impact on ia64.
Date: Thu, 05 Jun 2008 10:28:33 -0400	[thread overview]
Message-ID: <4847F811.7060406@redhat.com> (raw)
In-Reply-To: <1212653539.19205.47.camel@lappy.programming.kicks-ass.net>

Hi Peter and Mathieu,

Peter Zijlstra wrote:
> On Wed, 2008-06-04 at 19:22 -0400, Mathieu Desnoyers wrote:
>> * Peter Zijlstra (peterz@infradead.org) wrote:
> 
>>> So are you proposing something like:
>>>
>>> static inline void 
>>> trace_sched_switch(struct task_struct *prev, struct task_struct *next)
>>> {
>>> 	trace_mark(sched_switch, prev, next);
>>> }
>>>
>> Not exactly. Something more along the lines of
>>
>> static inline void 
>> trace_sched_switch(struct task_struct *prev, struct task_struct *next)
>> {
>>   /* Internal tracers. */
>>   ftrace_sched_switch(prev, next);
>>   othertracer_sched_switch(prev, next);
>>   /*
>>    * System-wide tracing. Useful information is exported here.
>>    * Probes connecting to these markers are expected to only use the
>>    * information provided to them for data collection purpose. Type
>>    * casting pointers is discouraged.
>>    */
>> 	trace_mark(kernel_sched_switch, "prev_pid %d next_pid %d prev_state %ld",
>>     prev->pid, next->pid, prev->state);
>> }
> 
> Advantage of my method would be that ftrace (and othertracer) can use
> the same marker and doesn't need yet another hoook.

If so, I'd like to suggest below changes,

- introduce below macro in marker.h

#define DEFINE_TRACE(name, vargs, args...)	\
static inline void trace_##name vargs		\
{						\
	trace_mark(name, #vargs, ##args);	\
}

- remove __marker_check_format from __trace_mark
- and write a definition in sched_trace.h

DEFINE_TRACE(sched_switch, (struct task_struct *prev, struct task_struct *next),
	     prev, next);

Thus, we can remove fmt string and also ensure the type checking, because;
- Type checking at the trace point is done by the compiler.
- Type checking of probe handler can be done by comparing #vargs strings.

Thanks,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


  reply	other threads:[~2008-06-05 14:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02 22:12 Kernel marker has no performance impact on ia64 Hideo AOKI
2008-06-02 22:32 ` Peter Zijlstra
2008-06-02 23:21   ` Mathieu Desnoyers
2008-06-03  6:07     ` Takashi Nishiie
2008-06-04  4:58     ` Masami Hiramatsu
2008-06-04 23:26       ` Mathieu Desnoyers
2008-06-04 23:40         ` Masami Hiramatsu
2008-06-04 22:27     ` Peter Zijlstra
2008-06-04 23:22       ` Mathieu Desnoyers
2008-06-05  8:12         ` Peter Zijlstra
2008-06-05 14:28           ` Masami Hiramatsu [this message]
2008-06-12 14:04             ` Mathieu Desnoyers
2008-06-12 15:31               ` Masami Hiramatsu
2008-06-12 13:53           ` Mathieu Desnoyers
2008-06-12 14:27             ` Peter Zijlstra
2008-06-12 15:53               ` Frank Ch. Eigler
2008-06-12 16:16                 ` Masami Hiramatsu
2008-06-12 16:43                   ` Frank Ch. Eigler
2008-06-12 16:56                     ` Peter Zijlstra
2008-06-12 22:10                       ` Mathieu Desnoyers
2008-06-12 17:05                     ` Masami Hiramatsu
2008-06-12 17:48                       ` Frank Ch. Eigler
2008-06-12 19:34                         ` Masami Hiramatsu
2008-06-13  4:19                           ` Takashi Nishiie
2008-06-13 18:02                             ` Masami Hiramatsu
2008-06-16  2:58                               ` Takashi Nishiie
2008-06-12 16:53                 ` Peter Zijlstra
2008-06-12 17:38                   ` Frank Ch. Eigler
2008-06-13 11:01                     ` Peter Zijlstra
2008-06-13 14:17                       ` Frank Ch. Eigler

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=4847F811.7060406@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=haoki@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --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.