Hi - On Sat, Jan 17, 2009 at 09:58:45PM -0600, Tom Tucker wrote: > [...] > >>I have a patch which changes the definition of the dprintk() macro > >>(but *not* dprintk() callsites) to allow enabling and disabling > >>individual dprintk() statements through a /proc/ interface. Would > >>you be interested in that? > > > >It would make more sense to me to turn dprintk's into trace_marks, then > >use http://lkml.org/lkml/2008/12/30/297 to control transmission of the > >data to ftrace. > [...] > That said, and sorry for my ignorance on trace markers, but: > > - Could you describe how we would define "classes" of trace markers. I > certainly don't want to have to turn on and off each call-site > individually. How would these classes be different than adding more bits > to the current rpc_debug mechanism? You're well prepared to reuse the classes you already have - see below. > - From Steve's patches, it's not obvious to me how we would convert > dprintk to trace markers without visiting every single call site. Can > the current macros be munged to use the trace marker interfaces without > losing debug information? The minimal possibility is to just do something like this: #define dprintk(format...) trace_mark(nfs_message, format) Or for the dfprintk that includes the facility symbol: #define dfprintk(facility,format...) trace_mark (nfs_#facility, format) The result would be to have one marker family for each {RPC,NFS,...}DBG_* type - or any other "facility" symbol you invent on the spot. All members of each family can be enabled by attaching a marker handler to the "nfs_FACILITY" name. With Lai's markers->ftrace proposed patch, this would be done from user-space by something like: echo -n 'nfs_FACILITY' > /debugfs/tracing/tracing_markers (You can take away the nfs_ prefix if you like.) > - What is the overhead of an "inactive" trace marker in data size > and execution time relative to a dprintk? It should be similar. The global {nfs,rpc,...}_debug numbers could go away and just rely on the marker's built-in on/off control API. > - What is the overhead of an "active" trace marker in data size and > execution time relative to a dprintk? If the markers end up being channeled to the ftrace buffers, it should be significantly lighter-weight than sending them to printk. If some other marker consumer connects also or instead, it depends on what that does. - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
