Re: [PATCH] Register read and writes tracing

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

 



Hi Prasad,

On 2020-09-28 06:04, Prasad Sodagudi wrote:
Qualcomm team have tried to upstreaming the register trace buffer(RTB)
use case earlier - [1]
with pstore approach. In that discussion, there was suggestion to use
the ftrace events for
tracking the register reads and writes. In this patch, added register
read/write operations
tracing support and also add _no_log variants(for example -
readl_relaxed_no_log  to readl_relaxed)
functions, which will help to avoid excessive logging for certain
register operations
(continuous writes from a loop). These tracepoints can be used by modules to register probes and log the data convenient for silicon vendor format.

[1] -
https://lore.kernel.org/lkml/cover.1535119710.git.saiprakash.ranjan@xxxxxxxxxxxxxx/


Thanks for picking this up again. This kind of looks like going back to
downstream implementation of having log and nolog variants which was
exactly the thing we wanted to avoid.

I believe the reason for this nolog variants is not just to avoid excessive logging but also to provide filtering i.e, selectively trace the register
reads/writes from required drivers or subsystems like for example we
wouldn't want to trace register reads/writes from serial drivers, now if
you use these nolog variants  then it will need to be sprinkled all over
the kernel in various drivers to provide this kind of filtering. That was the reason I did not want to introduce these nolog and log variants, instead introduced a way to use dynamic debug [2] to provide this kind of filtering. Dynamic debug provides an array of filtering capacity such as filter by files, folders and even is applicable for modules making it a prime candidate for
these kind of scenarios.

So why not use it instead of all these new variants? Then you don't have to export things like you do in this patch and just have to add tracepoints. Also the patch series[1][2] was almost OK'ed(they didn't give a formal review) by arm folks at the time and even acked by Steve[3] except for the pstore part. We have ways to extract trace events from ramdumps via crash utility or STM, so pstore support is not mandatory and can be done later(it is currently being worked on). Plus the link you mentioned was an RFC and there was a new version posted after that[4]. Please take at the series[4] look once and see if you can use that, only thing required I suppose is decouple the pstore patches
and you should be good to go.

[1] https://patchwork.kernel.org/patch/10593175/
[2] https://patchwork.kernel.org/patch/10593175/
[3] https://patchwork.kernel.org/patch/10593173/
[4] https://patchwork.kernel.org/cover/10593159/

Qualcomm teams uses these logs for debugging various issues in the
product life cycle and
hopping that this logging would help other silicon vendors as this is
generic approach.
Please provide your suggestion/comments to bring this patch upstream quality.

Prasad Sodagudi (1):
  tracing: Add register read and write tracing support

arch/arm64/include/asm/io.h | 117 ++++++++++++++++++++++++++++++++++++++---
 include/linux/iorw.h           |  20 +++++++
 include/trace/events/rwio.h    |  51 ++++++++++++++++++
 kernel/trace/Kconfig           |  11 ++++
 kernel/trace/Makefile          |   1 +
 kernel/trace/trace_readwrite.c |  30 +++++++++++
 6 files changed, 222 insertions(+), 8 deletions(-)
 create mode 100644 include/linux/iorw.h
 create mode 100644 include/trace/events/rwio.h
 create mode 100644 kernel/trace/trace_readwrite.c

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux