Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path

["Frank Ch. Eigler" <fche@redhat.com>]

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