From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Prasad Sodagudi <psodagud@codeaurora.org>
Cc: rostedt@goodmis.org, mingo@redhat.com, keescook@chromium.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
gregkh@linuxfoundation.org, anton@enomsg.org, arnd@arndb.de,
catalin.marinas@arm.com, ccross@android.com, jbaron@akamai.com,
jim.cromie@gmail.com, joe@perches.com, joel@joelfernandes.org,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH] Register read and writes tracing
Date: Mon, 28 Sep 2020 11:15:58 +0530 [thread overview]
Message-ID: <ecc13f64210678c99cfcf7285f80c0c0@codeaurora.org> (raw)
In-Reply-To: <1601253290-400618-1-git-send-email-psodagud@codeaurora.org>
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@codeaurora.org/
>
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
prev parent reply other threads:[~2020-09-28 5:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 0:34 [PATCH] Register read and writes tracing Prasad Sodagudi
2020-09-28 0:34 ` [PATCH] tracing: Add register read and write tracing support Prasad Sodagudi
2020-09-28 5:17 ` Greg KH
2020-09-28 5:20 ` Greg KH
2020-09-28 14:55 ` Steven Rostedt
2020-09-28 5:45 ` Sai Prakash Ranjan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ecc13f64210678c99cfcf7285f80c0c0@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=anton@enomsg.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=ccross@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=jbaron@akamai.com \
--cc=jim.cromie@gmail.com \
--cc=joe@perches.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=psodagud@codeaurora.org \
--cc=rostedt@goodmis.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).