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. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
