[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0mxRshs=OrOK+NaMharykS0PffATq30wJTv4qe52_ecg@mail.gmail.com>
Date: Mon, 6 Dec 2021 11:01:05 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Sai Prakash Ranjan <quic_saipraka@...cinc.com>
Cc: Arnd Bergmann <arnd@...db.de>, Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Marc Zyngier <maz@...nel.org>,
gregkh <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
quic_psodagud@...cinc.com
Subject: Re: [PATCHv5 4/4] asm-generic/io: Add logging support for MMIO accessors
On Mon, Dec 6, 2021 at 10:52 AM Sai Prakash Ranjan
<quic_saipraka@...cinc.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.
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 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.
Arnd
Powered by blists - more mailing lists