[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-pm
Subject:    Re: [PATCH v2] PM: trace events for suspend/resume
From:       Steven Rostedt <rostedt () goodmis ! org>
Date:       2014-05-31 3:07:45
Message-ID: 20140530230745.7388be84 () gandalf ! local ! home
[Download RAW message or body]

On Fri, 30 May 2014 19:58:52 -0700
Todd E Brandt <todd.e.brandt@linux.intel.com> wrote:


> > This will export the strings into debugfs/tracing/printk_formats so
> > that the pointer can be mapped to a string.
> 
> ahh, ok, yea if there's some performance impact of using tracepoints this
> way then I'll definately change that, thanks for the example.

It speeds up the tracing and compacts it a bit. It has no affect when
tracing is disabled.

> 
> > 
> > This is assuming that all of these calls are in core kernel code and
> > not in modules. Are they?
> 
> No these are all core code. I double-checked all the Kconfigs to make
> sure none of those files are configured by tristate options, they're
> all bool. I also test ran a few compiles with CONFIG_PM disabled just
> to be sure that nothing broke in kernel/cpu.c and all was well.

After checking, it didn't really matter if they were used by modules or
not. Just that their strings were all constants.
 
> > Here you would have:
> > 
> > 	TP_printk("%s[%u] %s", entry->action,
> > 
> > You just need to add that TPS() around all strings where it is passed
> > to the tracepoint and it will still work with trace-cmd and perf.
> 
> Is is legal to pass a format string to a tracepoint which then gets fed
> into TP_printk? i.e.
> 
> TP_printk(__get_str(fmtstring), __entry->val)
> 
> I didn't do that since I couldn't find a single example of that in the other
> trace events, but theoretically it should be safe.

Hmm, was there an example where you wanted that? That's not what I was
suggesting. It may work for a tracepoint, but it will definitely screw
up trace-cmd and perf.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]