[dm-devel] [PATCH 21/24] dm cache: add trc policy shim

Mike Snitzer snitzer at redhat.com
Fri Nov 1 23:38:17 UTC 2013


On Fri, Nov 01 2013 at  5:39pm -0400,
Steven Rostedt <srostedt at redhat.com> wrote:

> > > 
> > > Think this would take care of it (not full-blown tracepoints like
> > > blktrace but certainly more performant than standard printk):
> 
> What's wrong with full blown tracepoints?

Nothing.  Just wasn't as quick to switch to while keeping the intent of
the original implementation.

> > I folded this trace_printk change in and renamed from trc to trace, see:
> > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=f6f5db50495b16ff23a0febf38f9ee9d964b12dd
> > 
> 
> Please please please DO NOT USE TRACE_PRINTK!

Sure, I'll have a look at using proper tracepoints.  Worst case, in the
near-term, we drop this type of patch for v3.13 considering how close we
are to merge.

> It's a debugging tool, and should never be used in the kernel proper. It
> was meant for users to use it for debugging and then strip it out.
> 
> Now what you could do is to set up tracepoints to record the information
> you want, either in the function itself, or add the wrapper function too
> as a separate policy. Not sure if that would be any help or not.
> 
> But unless this is something that is considered "debug use only" and
> never put into a production kernel, do not use trace_printk().

It really is debug only, but I cannot promise nobody will ever add a
trace layer in production -- especially if it is as easy as using
"trace+mq" vs "mq" when specifying the policy name.

> Note, tracepoints will also give you the ability to pick and choose the
> traces instead of doing it by trace_level.

Yeap, I'm aware.

Thanks for your feedback Steve.




More information about the dm-devel mailing list