All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	<quic_psodagud@quicinc.com>, Marc Zyngier <maz@kernel.org>,
	<gregkh@linuxfoundation.org>, <arnd@arndb.de>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<mingo@redhat.com>, <jbaron@akamai.com>, <jim.cromie@gmail.com>
Subject: Re: [PATCHv3 3/3] dynamic_debug: Add a flag for dynamic event tracing
Date: Tue, 9 Nov 2021 21:52:26 +0530	[thread overview]
Message-ID: <f7c665b9-dc17-5a7f-de80-9fa0605721fc@quicinc.com> (raw)
In-Reply-To: <20211109104941.2d50eafc@gandalf.local.home>

Hi Steve,

On 11/9/2021 9:19 PM, Steven Rostedt wrote:
> On Tue, 9 Nov 2021 17:38:21 +0530
> Sai Prakash Ranjan <quic_saipraka@quicinc.com> wrote:
>
>> Debugging a specific driver or subsystem can be a lot easier if we can
>> trace events specific to that driver or subsystem. This type of
>> filtering can be achieved using existing dynamic debug library which
>> provides a way to filter based on files, functions and modules.
>>
>> Using this, provide an additional flag 'e' to filter event tracing to
>> specified input.
>>
>> For example, tracing all MMIO read/write can be overwhelming and of no
>> use when debugging a specific driver or a subsystem. So switch to
>> dynamic event tracing for register accesses.
>>
>> Example: Tracing register accesses for all drivers in drivers/soc/qcom/*
>> and the trace output is given below:
>>
>>    # dyndbg="file drivers/soc/qcom/* +e" trace_event=rwmmio
>>      or
>>    # echo "file drivers/soc/qcom/* +e" > /sys/kernel/debug/dynamic_debug/control
>>    # cat /sys/kernel/debug/tracing/trace
> FYI, it's best to use /sys/kernel/tracing, as the debug/tracing is only
> there for backward compatibility.

Ah I see, will correct it.


>>      rwmmio_read: rpmh_rsc_probe+0x35c/0x410 readl addr=0xffff80001071000c
>>      rwmmio_read: rpmh_rsc_probe+0x3d0/0x410 readl addr=0xffff800010710004
>>      rwmmio_write: rpmh_rsc_probe+0x3b0/0x410 writel addr=0xffff800010710d00 val=0x3
>>      rwmmio_write: write_tcs_cmd+0x6c/0x78 writel addr=0xffff800010710d30 val=0x10108
> I'd much rather have a module name or something attached to the event that
> ca be filtered on via the trace event filters, than having it determined by
> some side effect done in another directory.

I presume we don't have CALLER_MODULENAME0,1,2.. like CALLER_ADDR0,1,2 
without which we
cannot insert the module name to this trace event since MMIO accessors 
are defined in low level
arch headers and we won't get any useful module information from where 
these accessors are
called. The function name and the offset is good enough to identify the 
exact line and module after
post-processing with tools like GDB, objdump, so I feel we can keep the 
trace event fields limited?

Thanks,
Sai

>
> -- Steve



WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 <quic_psodagud@quicinc.com>, Marc Zyngier <maz@kernel.org>,
	<gregkh@linuxfoundation.org>, <arnd@arndb.de>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<mingo@redhat.com>, <jbaron@akamai.com>, <jim.cromie@gmail.com>
Subject: Re: [PATCHv3 3/3] dynamic_debug: Add a flag for dynamic event tracing
Date: Tue, 9 Nov 2021 21:52:26 +0530	[thread overview]
Message-ID: <f7c665b9-dc17-5a7f-de80-9fa0605721fc@quicinc.com> (raw)
In-Reply-To: <20211109104941.2d50eafc@gandalf.local.home>

Hi Steve,

On 11/9/2021 9:19 PM, Steven Rostedt wrote:
> On Tue, 9 Nov 2021 17:38:21 +0530
> Sai Prakash Ranjan <quic_saipraka@quicinc.com> wrote:
>
>> Debugging a specific driver or subsystem can be a lot easier if we can
>> trace events specific to that driver or subsystem. This type of
>> filtering can be achieved using existing dynamic debug library which
>> provides a way to filter based on files, functions and modules.
>>
>> Using this, provide an additional flag 'e' to filter event tracing to
>> specified input.
>>
>> For example, tracing all MMIO read/write can be overwhelming and of no
>> use when debugging a specific driver or a subsystem. So switch to
>> dynamic event tracing for register accesses.
>>
>> Example: Tracing register accesses for all drivers in drivers/soc/qcom/*
>> and the trace output is given below:
>>
>>    # dyndbg="file drivers/soc/qcom/* +e" trace_event=rwmmio
>>      or
>>    # echo "file drivers/soc/qcom/* +e" > /sys/kernel/debug/dynamic_debug/control
>>    # cat /sys/kernel/debug/tracing/trace
> FYI, it's best to use /sys/kernel/tracing, as the debug/tracing is only
> there for backward compatibility.

Ah I see, will correct it.


>>      rwmmio_read: rpmh_rsc_probe+0x35c/0x410 readl addr=0xffff80001071000c
>>      rwmmio_read: rpmh_rsc_probe+0x3d0/0x410 readl addr=0xffff800010710004
>>      rwmmio_write: rpmh_rsc_probe+0x3b0/0x410 writel addr=0xffff800010710d00 val=0x3
>>      rwmmio_write: write_tcs_cmd+0x6c/0x78 writel addr=0xffff800010710d30 val=0x10108
> I'd much rather have a module name or something attached to the event that
> ca be filtered on via the trace event filters, than having it determined by
> some side effect done in another directory.

I presume we don't have CALLER_MODULENAME0,1,2.. like CALLER_ADDR0,1,2 
without which we
cannot insert the module name to this trace event since MMIO accessors 
are defined in low level
arch headers and we won't get any useful module information from where 
these accessors are
called. The function name and the offset is good enough to identify the 
exact line and module after
post-processing with tools like GDB, objdump, so I feel we can keep the 
trace event fields limited?

Thanks,
Sai

>
> -- Steve



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-11-09 16:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 12:08 [PATCHv3 0/3] tracing/rwmmio/arm64: Add support to trace register reads/writes Sai Prakash Ranjan
2021-11-09 12:08 ` Sai Prakash Ranjan
2021-11-09 12:08 ` [PATCHv3 1/3] tracing: Add register read/write tracing support Sai Prakash Ranjan
2021-11-09 12:08   ` Sai Prakash Ranjan
2021-11-09 13:54   ` Steven Rostedt
2021-11-09 13:54     ` Steven Rostedt
2021-11-09 14:12     ` Sai Prakash Ranjan
2021-11-09 14:12       ` Sai Prakash Ranjan
2021-11-10 22:56   ` kernel test robot
2021-11-10 22:56     ` kernel test robot
2021-11-09 12:08 ` [PATCHv3 2/3] arm64/io: Add a header for mmio access instrumentation Sai Prakash Ranjan
2021-11-09 12:08   ` Sai Prakash Ranjan
2021-11-09 12:08 ` [PATCHv3 3/3] dynamic_debug: Add a flag for dynamic event tracing Sai Prakash Ranjan
2021-11-09 12:08   ` Sai Prakash Ranjan
2021-11-09 15:49   ` Steven Rostedt
2021-11-09 15:49     ` Steven Rostedt
2021-11-09 16:22     ` Sai Prakash Ranjan [this message]
2021-11-09 16:22       ` Sai Prakash Ranjan
2021-11-09 16:59       ` Steven Rostedt
2021-11-09 16:59         ` Steven Rostedt
2021-11-09 17:30         ` Sai Prakash Ranjan
2021-11-09 17:30           ` Sai Prakash Ranjan
2021-11-09 17:40           ` Steven Rostedt
2021-11-09 17:40             ` Steven Rostedt
2021-11-09 17:49             ` Sai Prakash Ranjan
2021-11-09 17:49               ` Sai Prakash Ranjan
2021-11-09 21:42               ` Jason Baron
2021-11-09 21:42                 ` Jason Baron
2021-11-09 21:51                 ` Steven Rostedt
2021-11-09 21:51                   ` Steven Rostedt
2021-11-09 22:13                   ` Jason Baron
2021-11-09 22:13                     ` Jason Baron
2021-11-09 22:28                     ` Steven Rostedt
2021-11-09 22:28                       ` Steven Rostedt
2021-11-10 20:03                       ` Jason Baron
2021-11-10 20:03                         ` Jason Baron
2021-11-11 13:24                       ` Mathieu Desnoyers
2021-11-11 13:24                         ` Mathieu Desnoyers

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=f7c665b9-dc17-5a7f-de80-9fa0605721fc@quicinc.com \
    --to=quic_saipraka@quicinc.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jbaron@akamai.com \
    --cc=jim.cromie@gmail.com \
    --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=mingo@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.