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
next prev parent 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: linkBe 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.