Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Marc Zyngier <maz@kernel.org>,
	gregkh <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	<quic_psodagud@quicinc.com>
Subject: Re: [PATCHv5 4/4] asm-generic/io: Add logging support for MMIO accessors
Date: Mon, 6 Dec 2021 15:50:18 +0530	[thread overview]
Message-ID: <7e5dbbf5-2385-ddb3-bf88-66e347d7d5e9@quicinc.com> (raw)
In-Reply-To: <CAK8P3a0mxRshs=OrOK+NaMharykS0PffATq30wJTv4qe52_ecg@mail.gmail.com>

On 12/6/2021 3:31 PM, Arnd Bergmann wrote:
> On Mon, Dec 6, 2021 at 10:52 AM Sai Prakash Ranjan
> <quic_saipraka@quicinc.com> wrote:
>> Yes just the trace after read/write won't serve our usecase where we
>> expect crashes/hangs on accessing
>> these registers but internally we did have a log_post_read_mmio() as
>> well, if it is useful then I can add it.
> Are there any downsides to tracing both before and after, besides another growth
> in binary size? Aside from the 'value', that would also allow
> measuring the time it
> takes to complete a readl(), which may be valuable for other users as these
> can be significant.

Ah yes, that would be useful. No downsides as far as I know other than 
the size
but that should be fine given this depends on ftrace.

>
> Not sure how to best do that that, we could return a timestamp from the 'before'
> tracepoint and pass it into the 'after' tracepoint in order to log the
> difference, or just
> rely on calculating the differences in user space based on the log.

For trace events, timing information is already logged by ftrace 
infrastructure. Most of the users do
use these for timing information based on post processing these logs 
looking at these timestamps,
so we should be good using that as well.


> For the 'write' style accessors, the timing data would be less interesting, at
> least for posted PCI transactions, but it may be helpful to do the same for
> symmetry reasons.

Ok, I will add these post read/write logging in the next version.

Thanks,
Sai



      reply	other threads:[~2021-12-06 10:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06  8:28 [PATCHv5 0/4] tracing/rwmmio/arm64: Add support to trace register reads/writes Sai Prakash Ranjan
2021-12-06  8:28 ` [PATCHv5 1/4] arm64: io: Use asm-generic high level MMIO accessors Sai Prakash Ranjan
2021-12-06  8:50   ` Arnd Bergmann
2021-12-06 11:12     ` Sai Prakash Ranjan
2021-12-06 11:30       ` Arnd Bergmann
2021-12-06 13:52         ` Sai Prakash Ranjan
2021-12-06 15:15           ` Arnd Bergmann
2021-12-06 15:57             ` Sai Prakash Ranjan
2021-12-06 15:36   ` kernel test robot
2021-12-07 13:04   ` kernel test robot
2021-12-06  8:28 ` [PATCHv5 2/4] irqchip/tegra: Fix overflow implicit truncation warnings Sai Prakash Ranjan
2021-12-06  8:51   ` Arnd Bergmann
2021-12-06  8:28 ` [PATCHv5 3/4] tracing: Add register read/write tracing support Sai Prakash Ranjan
2021-12-06  8:59   ` Arnd Bergmann
2021-12-06 10:11     ` Sai Prakash Ranjan
2021-12-06 10:46       ` Arnd Bergmann
2021-12-06 10:52         ` Sai Prakash Ranjan
2021-12-06 10:13     ` Sai Prakash Ranjan
2021-12-06 11:52   ` kernel test robot
2021-12-06 16:39   ` kernel test robot
2021-12-06  8:28 ` [PATCHv5 4/4] asm-generic/io: Add logging support for MMIO accessors Sai Prakash Ranjan
2021-12-06  9:09   ` Arnd Bergmann
2021-12-06  9:52     ` Sai Prakash Ranjan
2021-12-06 10:01       ` Arnd Bergmann
2021-12-06 10:20         ` 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=7e5dbbf5-2385-ddb3-bf88-66e347d7d5e9@quicinc.com \
    --to=quic_saipraka@quicinc.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=quic_psodagud@quicinc.com \
    --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