Re: [PATCH v4] tty/serial: create debugfs interface for UART register tracing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 15, 2023 at 06:04:17PM -0600, Dan Raymond wrote:
> 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.

Thanks!

In my opinion this work is good to have published, but still doesn't warrant
to be part of the Linux kernel with the other method being worked.

Let's hear others' opinions, though...

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux