Re: [ath5k-devel] [PATCH/RFC 3/3] ath5k: trace resets

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Tue, Jul 20, 2010 at 06:04:59PM -0700, Bruno Randolf wrote:
> On Tue July 20 2010 23:52:00 Bob Copeland wrote:
> > > again, here my same concerns: printing the reasons for resets is
> > > something which is useful on embedded boards and production setups which
> > > can't have tracing enabled. which is why i want to object against this
> > > change!
> > 
> > What Johannes said wrt performance: during tracing, only the binary
> > representations of the data are written to the trace ring buffer, so
> > unlike the current debug code, we aren't doing printk formatting until
> > the trace buffer is read.  You can save the raw binary data from the
> > trace and do formatting on another machine.
> 
> that's true, but try to run a kernel with tracing compiled in and NOT runtime 
> enabled on a small embedded board (soekris net48xx for example) and you'll see 
> the difference. without tracing you can get 22Mbps, with tracing max 15Mbps 
> UDP thruput. that means you cannot run a kernel with tracing enabled on a 
> production system, which also means you cannot log the reasons for a reset 
> there any more. and most of the problems we what to trace (e.g. stuck queue) 
> happen only after days or weeks of operation in production environments...
>  
> > Another advantage is better granularity: if you only care about watching
> > tx on the cab queue, you can dynamically filter based on the tracepoint
> > arguments, something like:
> > 
> >   # echo "qnum == 6" > /debug/tracing/events/ath5k/ath5k_tx/filter
> > 
> > With the debug printks, you have to hack the driver or grep and hope
> > the printk buffer didn't overflow and spill what you were looking for.
> 
> no doubt, i can see the advantages...
> 
> so let's go ahead with tracing, since we can always build less performant 
> tracing kernels when we want to track down problems.

FWIW I intend on adding tracing as well to ath9k_hw on the hw-ops.
Hence the hw-ops.h file, etc.

  Luis