Mailing List Archive: [PATCH v3 0/6] tracing: export event trace and trace

[PATCH v3 0/6] tracing: export event trace and trace_marker

Jul 27, 2020, 8:15 PM

Post #1 of 4 (75 views)

Ftrace has ability to export trace packets to other destination.
Currently, only function trace can be exported. This series extends the
support to event trace and trace_maker. STM is one possible destination to
export ftrace. Use separate channel for each CPU to avoid mixing up packets
from different CPUs together.

Change from v2:
Change flag definition to BIT(). (Steven)
Add comment in stm_ftrace_write() to clarify it's safe to use
smp_processor_id() here since preempt is disabled. (Steven)

Change from v1:
All changes are suggested by Steven Rostedt.
User separate flag to control function trace, event trace and trace mark.
Allocate channels according to num_possible_cpu() dynamically.
Move ftrace_exports routines up so all ftrace can use them.

Tingwei Zhang (6):
stm class: ftrace: change dependency to TRACING
tracing: add flag to control different traces
tracing: add trace_export support for event trace
tracing: add trace_export support for trace_marker
stm class: ftrace: enable supported trace export flag
stm class: ftrace: use different channel accroding to CPU

drivers/hwtracing/stm/Kconfig | 2 +-
drivers/hwtracing/stm/ftrace.c | 7 +-
include/linux/trace.h | 7 +
kernel/trace/trace.c | 270 ++++++++++++++++++---------------
4 files changed, 159 insertions(+), 127 deletions(-)

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 0/6] tracing: export event trace and trace_marker [ In reply to ]

tingweiz at codeaurora

Aug 10, 2020, 8:15 PM

Post #2 of 4 (75 views)

Permalink

Hi Steven,
On Tue, Jul 28, 2020 at 09:33:53AM +0800, Tingwei Zhang wrote:
> Ftrace has ability to export trace packets to other destination.
> Currently, only function trace can be exported. This series extends the
> support to event trace and trace_maker. STM is one possible destination to
> export ftrace. Use separate channel for each CPU to avoid mixing up
> packets
> from different CPUs together.
>
> Change from v2:
> Change flag definition to BIT(). (Steven)
> Add comment in stm_ftrace_write() to clarify it's safe to use
> smp_processor_id() here since preempt is disabled. (Steven)

Thanks for your comments, Steven. I've addressed all your comments in v3.
Do you have more comments on v3? Is there anything I need to do to merge
this series to Linux Kernel?

>
> Change from v1:
> All changes are suggested by Steven Rostedt.
> User separate flag to control function trace, event trace and trace mark.
> Allocate channels according to num_possible_cpu() dynamically.
> Move ftrace_exports routines up so all ftrace can use them.
>
> Tingwei Zhang (6):
> stm class: ftrace: change dependency to TRACING
> tracing: add flag to control different traces
> tracing: add trace_export support for event trace
> tracing: add trace_export support for trace_marker
> stm class: ftrace: enable supported trace export flag
> stm class: ftrace: use different channel accroding to CPU
>
> drivers/hwtracing/stm/Kconfig | 2 +-
> drivers/hwtracing/stm/ftrace.c | 7 +-
> include/linux/trace.h | 7 +
> kernel/trace/trace.c | 270 ++++++++++++++++++---------------
> 4 files changed, 159 insertions(+), 127 deletions(-)
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

Re: [PATCH v3 0/6] tracing: export event trace and trace_marker [ In reply to ]

rostedt at goodmis

Aug 10, 2020, 10:15 PM

Post #3 of 4 (74 views)

Permalink

On Tue, 11 Aug 2020 11:04:18 +0800
Tingwei Zhang <tingweiz@codeaurora.org> wrote:

> Thanks for your comments, Steven. I've addressed all your comments in v3.
> Do you have more comments on v3? Is there anything I need to do to merge
> this series to Linux Kernel?

I gave my Reviewed-by tag on each of the patches that touch my tree. It
should go in via whoever maintains the drivers/hwtracing tree. Is that
Greg KH?

-- Steve

Re: [PATCH v3 0/6] tracing: export event trace and trace_marker [ In reply to ]

tingweiz at codeaurora

Aug 11, 2020, 12:15 AM

Post #4 of 4 (74 views)

Permalink

On Tue, Aug 11, 2020 at 12:03:33PM +0800, Steven Rostedt wrote:
> On Tue, 11 Aug 2020 11:49:46 +0800
> Tingwei Zhang <tingweiz@codeaurora.org> wrote:
>
> > On Tue, Aug 11, 2020 at 11:19:54AM +0800, Steven Rostedt wrote:
> > > On Tue, 11 Aug 2020 11:04:18 +0800
> > > Tingwei Zhang <tingweiz@codeaurora.org> wrote:
> > >
> > > > Thanks for your comments, Steven. I've addressed all your comments
> in
> > > v3.
> > > > Do you have more comments on v3? Is there anything I need to do to
> merge
> > > > this series to Linux Kernel?
> > >
> > > I gave my Reviewed-by tag on each of the patches that touch my tree.
> It
> > > should go in via whoever maintains the drivers/hwtracing tree. Is that
> > > Greg KH?
> > I thought it will go to tracing tree since majority of the changes are
> in
> > kernel/trace.
> >
> > Maintainers of drviers/hwtracing are Mathieu and Suzuki. I'll add them
> > into review list.
> >
>
> As I didn't have reviews or acks from them. I couldn't take the code.
> When touching two subsystems, it usually requires one of the subsystem
> maintainers to ack the changes to their subsystem, so that the other
> subsystem maintainer can take the rest of the code through their tree.
>
> And it usually goes through the tree that has the interface that is
> changing. That is, the changes to tracing was the infrastructure
> needed for the changes in the hwtrace subsystem. And I don't test that
> subsystem, so I wouldn't really be able to test this code.
>
Thanks a lot for detail clarification, Steven.

Thanks,
Tingwei

> -- Steve