All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@huawei.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] tracing: more list_empty(perf_events) checks
Date: Mon, 17 Jun 2013 17:27:53 -0400	[thread overview]
Message-ID: <1371504473.18733.27.camel@gandalf.local.home> (raw)
In-Reply-To: <20130617201818.GA12349@redhat.com>

On Mon, 2013-06-17 at 22:18 +0200, Oleg Nesterov wrote:
> On 06/17, Oleg Nesterov wrote:
> >
> > DECLARE_EVENT_CLASS()->perf_trace_##call() is not trivial because
> > of __perf_task()
> 
> Perhaps we can do something like below?

Did this actually compile for you?

> 
> Then we can
> 
> 	1. kill __perf_addr(), __perf_count(), __perf_task() and
> 	   TP_perf_assign()
> 
> 	2. Add the fast path check
> 
> 		if (builtin_constant(__task) && !__task &&
> 		    hlist_empty(head)))
> 			return;
> 
> 	   into perf_trace_call() right after ftrace_get_offsets_call().
> 
> Doesn't look very nice, it relies on the fact that
> ftrace_get_offsets_call(args) evaluates TP_perf_arg()'s hidden in
> TP_ARGS().
> 
> OTOH, the whole point of include/trace/ is to create the code which
> nobody except the maintainers can understand. At least I certainly
> can't ;) So perhaps this is fine.

It's the land of the MAGIC MACROs. You must be a MACRO WIZARD to
understand. I don't understand it unless I put on my MACRO WIZARD HAT.



> 
> Oleg.
> 
> --- a/include/trace/events/sched.h
> +++ b/include/trace/events/sched.h
> @@ -57,7 +57,7 @@ DECLARE_EVENT_CLASS(sched_wakeup_template,
>  
>  	TP_PROTO(struct task_struct *p, int success),
>  
> -	TP_ARGS(p, success),
> +	TP_ARGS(TP_perf_arg(__task, p), success),
>  
>  	TP_STRUCT__entry(
>  		__array(	char,	comm,	TASK_COMM_LEN	)
> @@ -73,9 +73,6 @@ DECLARE_EVENT_CLASS(sched_wakeup_template,
>  		__entry->prio		= p->prio;
>  		__entry->success	= success;
>  		__entry->target_cpu	= task_cpu(p);
> -	)
> -	TP_perf_assign(
> -		__perf_task(p);
>  	),
>  
>  	TP_printk("comm=%s pid=%d prio=%d success=%d target_cpu=%03d",
> @@ -313,7 +310,7 @@ DECLARE_EVENT_CLASS(sched_stat_template,
>  
>  	TP_PROTO(struct task_struct *tsk, u64 delay),
>  
> -	TP_ARGS(tsk, delay),
> +	TP_ARGS(TP_perf_arg(__task, tsk), TP_perf_arg(__count, delay)),
>  
>  	TP_STRUCT__entry(
>  		__array( char,	comm,	TASK_COMM_LEN	)
> @@ -325,10 +322,6 @@ DECLARE_EVENT_CLASS(sched_stat_template,
>  		memcpy(__entry->comm, tsk->comm, TASK_COMM_LEN);
>  		__entry->pid	= tsk->pid;
>  		__entry->delay	= delay;
> -	)
> -	TP_perf_assign(
> -		__perf_count(delay);
> -		__perf_task(tsk);
>  	),
>  
>  	TP_printk("comm=%s pid=%d delay=%Lu [ns]",
> --- a/include/trace/ftrace.h
> +++ b/include/trace/ftrace.h
> @@ -506,6 +506,9 @@ static inline notrace int ftrace_get_offsets_##call(			\
>  #undef TP_perf_assign
>  #define TP_perf_assign(args...)
>  
> +#undef TP_perf_arg
> +#define TP_perf_arg(var, val)	(val)
> +
>  #undef DECLARE_EVENT_CLASS
>  #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print)	\
>  									\
> @@ -643,6 +646,9 @@ __attribute__((section("_ftrace_events"))) *__event_##call = &event_##call
>  #undef TP_perf_assign
>  #define TP_perf_assign(args...) args
>  
> +#undef TP_perf_arg
> +#define TP_perf_arg(var, val)	(var = (val))
> +
>  #undef DECLARE_EVENT_CLASS
>  #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print)	\
>  static notrace void							\
> @@ -659,13 +665,12 @@ perf_trace_##call(void *__data, proto)					\
>  	int __data_size;						\
>  	int rctx;							\
>  									\
> -	perf_fetch_caller_regs(&__regs);				\
> -									\
>  	__data_size = ftrace_get_offsets_##call(&__data_offsets, args); \

OK, so here the task gets assigned the val, and so does count.

This may not be a bad approach, but instead of having TP_perf_arg() in
events/sched.h, keep the TP_perf_task() and TP_perf_count(), and have
whatever is put there assigned. As "__task" and "__count" are hardcoded
into the macro. The you would have:

#undef TP_perf_task
#define TP_perf_task(val) (__task = (val))

#undef TP_perf_count
#define TP_perf_count(val) (__count = (val))

And that should work as well.

-- Steve


>  	__entry_size = ALIGN(__data_size + sizeof(*entry) + sizeof(u32),\
>  			     sizeof(u64));				\
>  	__entry_size -= sizeof(u32);					\
>  									\
> +	perf_fetch_caller_regs(&__regs);				\
>  	entry = (struct ftrace_raw_##call *)perf_trace_buf_prepare(	\
>  		__entry_size, event_call->event.type, &__regs, &rctx);	\
>  	if (!entry)							\



  reply	other threads:[~2013-06-17 21:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-17 17:01 [PATCH 0/3] tracing: more list_empty(perf_events) checks Oleg Nesterov
2013-06-17 17:02 ` [PATCH 1/3] tracing/function: Avoid perf_trace_buf_*() if event_function.perf_events is empty Oleg Nesterov
2013-06-17 17:02 ` [PATCH 2/3] tracing/syscall: Avoid perf_trace_buf_*() if sys_data->perf_events " Oleg Nesterov
2013-06-17 17:02 ` [PATCH 3/3] tracing/perf: Move the PERF_MAX_TRACE_SIZE check into perf_trace_buf_prepare() Oleg Nesterov
2013-06-17 20:18 ` [PATCH 0/3] tracing: more list_empty(perf_events) checks Oleg Nesterov
2013-06-17 21:27   ` Steven Rostedt [this message]
2013-06-18 14:46     ` Oleg Nesterov
2013-06-18 15:41       ` Steven Rostedt
2013-06-18 16:24         ` Oleg Nesterov
2013-07-18  3:00 ` Steven Rostedt
2013-07-18  9:42   ` Peter Zijlstra
2013-07-18 14:39     ` Steven Rostedt
2013-07-18 15:44       ` Oleg Nesterov
2013-07-18 15:53         ` Steven Rostedt
2013-07-18 16:11           ` Oleg Nesterov

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=1371504473.18733.27.camel@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=fweisbec@gmail.com \
    --cc=jovi.zhangwei@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    /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.