I took Andy Shevchenko's suggestion and added port I/O tracing in
a similar manner as the memory-mapped I/O tracing enabled with
CONFIG_TRACE_MMIO_ACCESS. I'll be submitting another patch for
that shortly. It works well and it provides another way to trace
UART register accesses. For most purposes it is probably superior to
the method used in this patch because it leverages the existing kernel
tracing framework.
However, this patch might still be useful for debugging issues that
are sensitive to timing because it uses less CPU resources. It also
uses less memory so a larger trace can be collected. I did some more
timing analysis and tried to minimize the impact of cache misses by
reading the MSR register 100 times in a loop. I added this test to
serial8250_do_get_mctrl() and ran 'cat /proc/tty/driver/serial' to
exercise the test. Here are the results (trace overhead is measured
in CPU cycles at 1GHz):
overhead method
-------- ------------------------------------------
0 serial_debugfs disabled
158 serial_debugfs enabled without pipe reader
367 serial_debugfs enabled with pipe reader
2 portio_tracefs disabled
461 portio_tracefs enabled but filtered
713 portio_tracefs enabled and collected
I made a few changes to v4 of this patch to support pipe semantics
similar to how /sys/kernel/tracing/trace_pipe works. You can now get
unlimited trace depth by piping the trace buffer to disk as follows:
cat /sys/kernel/debug/ttyS1/trace_pipe > trace.txt &
The 'cat' process will run in the background and it will terminate
when tracing is disabled. This doesn't come for free, however. The
wake_up() call adds a fair amount of overhead when a pipe reader is
present as you can see in the measurements above.
