On Tue, 2010-11-23 at 16:37 +0200, Avi Kivity wrote: > On 11/23/2010 04:30 PM, Steven Rostedt wrote: > > On Tue, 2010-11-23 at 13:04 +0200, Avi Kivity wrote: > > > On 11/16/2010 05:13 PM, Steven Rostedt wrote: > > > > BTW, what does /debug/tracing/printk_formats show? > > > > > > > > > > Empty. > > > > > > > So you have real trace_printk's not bprintk's? > > > > What are bprintk()s? trace_printk() tries to be clever. If it detects that the format is constant, instead of doing the sprintf at the tracepoint, it copies a pointer to the format, and then copies the args to the stack. (although, I'm not sure how much quicker this is). It just saves on the format in the ring buffer. If the format is not static, then it just simply calls __trace_printk() that does the sprintf() and writes that output into the buffer. > > > That is, if the format is not a const, then we fall back to > > __trace_printk(_THIS_IP_, fmt, args); > > > > And this is a different object. I have not tested these in a while, I'll > > give it a try. > > > > But if your printks are bprintks, then the bug is in the kernel, since > > that printk_formats needs to show something. > > What I do is sprinkle trace_printk()s around my code and expect to see > them interspersed with enabled tracepoints in 'trace-cmd report'. Is > that not the intended behaviour? > No, that is exactly the intended behavior. But the problem is, for some reason, the bprintk's (the default that trace_printk() uses) is not having the format exported. Remember, only the pointer to the format is stored in the ring buffer (and thus exported by trace-cmd). If that format is not shown in the printk_format's than trace-cmd has no way to determine what that trace_printk's format was. I guess the question is, why did it not show up? Again, the work around is to replace your trace_printks() with __trace_printk(_THIS_IP_, ...) or just modify the trace_printk() macro in include/linux/kernel.h to always use the __trace_printk() version. -- Steve -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
