mbox series

[V2,0/9] rtla improvements

Message ID cover.1684863094.git.bristot@kernel.org (mailing list archive)
Headers show
Series rtla improvements | expand

Message

Daniel Bristot de Oliveira May 23, 2023, 5:44 p.m. UTC
This is a series of improvements for rtla, mainly as a result of our
daily usage of the tool debugging problems at red hat.

The cgroup support and house keeping options are from our usage
of the tool debugging containers.

The auto-analysis overhead reduction is needed when we go to
large boxes - but it is really hand in practice, as it gives an idea
of the problem without having to look at the trace.

Running hwnoise 100 % of CPU time might cause some systems
to slow down too much. Reduce its utilization to 75% by default to
avoid problems for people using it for the first time.

Finally, it adds support for running timerlat user-space threads,
and to collect the additional field via rtla timerlat top.

Changes from V1:
  - Add the user-space thread support to rtla timerlat top
    Link: https://lore.kernel.org/lkml/cover.1683827510.git.bristot@kernel.org/

Daniel Bristot de Oliveira (9):
  rtla: Add -C cgroup support
  rtla: Add --house-keeping option
  rtla: Change monitored_cpus from char * to cpu_set_t
  rtla: Automatically move rtla to a house-keeping cpu
  rtla/timerlat: Give timerlat auto analysis its own instance
  rtla/timerlat_hist: Add auto-analysis support
  rtla: Start the tracers after creating all instances
  rtla/hwnoise: Reduce runtime to 75%
  rtla: Add timerlat user-space support for timerlat top

 Documentation/tools/rtla/common_options.rst   |   8 +
 .../tools/rtla/common_timerlat_aa.rst         |   7 -
 .../tools/rtla/rtla-timerlat-hist.rst         |   7 +-
 .../tools/rtla/rtla-timerlat-top.rst          |  14 +
 tools/tracing/rtla/src/osnoise.c              |  65 ++++
 tools/tracing/rtla/src/osnoise.h              |   5 +
 tools/tracing/rtla/src/osnoise_hist.c         |  90 ++++-
 tools/tracing/rtla/src/osnoise_top.c          |  83 ++++-
 tools/tracing/rtla/src/timerlat_aa.c          |  35 +-
 tools/tracing/rtla/src/timerlat_aa.h          |   5 +-
 tools/tracing/rtla/src/timerlat_hist.c        | 139 +++++++-
 tools/tracing/rtla/src/timerlat_top.c         | 229 +++++++++++--
 tools/tracing/rtla/src/timerlat_u.c           | 224 ++++++++++++
 tools/tracing/rtla/src/timerlat_u.h           |  18 +
 tools/tracing/rtla/src/utils.c                | 324 +++++++++++++++++-
 tools/tracing/rtla/src/utils.h                |   7 +
 16 files changed, 1162 insertions(+), 98 deletions(-)
 create mode 100644 tools/tracing/rtla/src/timerlat_u.c
 create mode 100644 tools/tracing/rtla/src/timerlat_u.h

Comments

Steven Rostedt May 29, 2023, 8:28 a.m. UTC | #1
Hi Daniel,

Could you make sure to Cc linux-trace-kernel@vger.kernel.org and not
linux-trace-devel. The former is for any patch that goes into the
kernel repo, the later is for the tracing libraries (like libtracefs).
The reason why this matters is that the patchwork that is associated to
the Linux kernel tree will not get these (and I will not work on them
when I'm working on kernel patches). But it will go into the 
patchwork for the libraries (and never be processed by the patchwork
infrastructure), and I will likely not work on them, because when I
look at the library patchwork, I ignore anything that goes into the
kernel.

Perhaps resend with the proper Cc and it will then be processed. I
allowed this to happen before, but that's because I did everything
manually and not with my scripts. And I'm tired of doing that.

Thanks,

-- Steve


On Tue, 23 May 2023 19:44:22 +0200
Daniel Bristot de Oliveira <bristot@kernel.org> wrote:

> This is a series of improvements for rtla, mainly as a result of our
> daily usage of the tool debugging problems at red hat.
> 
> The cgroup support and house keeping options are from our usage
> of the tool debugging containers.
> 
> The auto-analysis overhead reduction is needed when we go to
> large boxes - but it is really hand in practice, as it gives an idea
> of the problem without having to look at the trace.
> 
> Running hwnoise 100 % of CPU time might cause some systems
> to slow down too much. Reduce its utilization to 75% by default to
> avoid problems for people using it for the first time.
> 
> Finally, it adds support for running timerlat user-space threads,
> and to collect the additional field via rtla timerlat top.
> 
> Changes from V1:
>   - Add the user-space thread support to rtla timerlat top
>     Link: https://lore.kernel.org/lkml/cover.1683827510.git.bristot@kernel.org/
> 
> Daniel Bristot de Oliveira (9):
>   rtla: Add -C cgroup support
>   rtla: Add --house-keeping option
>   rtla: Change monitored_cpus from char * to cpu_set_t
>   rtla: Automatically move rtla to a house-keeping cpu
>   rtla/timerlat: Give timerlat auto analysis its own instance
>   rtla/timerlat_hist: Add auto-analysis support
>   rtla: Start the tracers after creating all instances
>   rtla/hwnoise: Reduce runtime to 75%
>   rtla: Add timerlat user-space support for timerlat top
> 
>  Documentation/tools/rtla/common_options.rst   |   8 +
>  .../tools/rtla/common_timerlat_aa.rst         |   7 -
>  .../tools/rtla/rtla-timerlat-hist.rst         |   7 +-
>  .../tools/rtla/rtla-timerlat-top.rst          |  14 +
>  tools/tracing/rtla/src/osnoise.c              |  65 ++++
>  tools/tracing/rtla/src/osnoise.h              |   5 +
>  tools/tracing/rtla/src/osnoise_hist.c         |  90 ++++-
>  tools/tracing/rtla/src/osnoise_top.c          |  83 ++++-
>  tools/tracing/rtla/src/timerlat_aa.c          |  35 +-
>  tools/tracing/rtla/src/timerlat_aa.h          |   5 +-
>  tools/tracing/rtla/src/timerlat_hist.c        | 139 +++++++-
>  tools/tracing/rtla/src/timerlat_top.c         | 229 +++++++++++--
>  tools/tracing/rtla/src/timerlat_u.c           | 224 ++++++++++++
>  tools/tracing/rtla/src/timerlat_u.h           |  18 +
>  tools/tracing/rtla/src/utils.c                | 324 +++++++++++++++++-
>  tools/tracing/rtla/src/utils.h                |   7 +
>  16 files changed, 1162 insertions(+), 98 deletions(-)
>  create mode 100644 tools/tracing/rtla/src/timerlat_u.c
>  create mode 100644 tools/tracing/rtla/src/timerlat_u.h
>
Daniel Bristot de Oliveira May 29, 2023, 8:38 a.m. UTC | #2
On 5/29/23 10:28, Steven Rostedt wrote:
> Hi Daniel,
> 
> Could you make sure to Cc linux-trace-kernel@vger.kernel.org and not
> linux-trace-devel. The former is for any patch that goes into the
> kernel repo, the later is for the tracing libraries (like libtracefs).
> The reason why this matters is that the patchwork that is associated to
> the Linux kernel tree will not get these (and I will not work on them
> when I'm working on kernel patches). But it will go into the 
> patchwork for the libraries (and never be processed by the patchwork
> infrastructure), and I will likely not work on them, because when I
> look at the library patchwork, I ignore anything that goes into the
> kernel.

Sure, I will do that. IIRC, we agreed that we would use linux-trace-devel for
rtla because it is a user-space tool. But I agree with you, as they are patches
going to the kernel repo, linux-trace-kernel is a better place. It is easier to
myself too... :-).

> 
> Perhaps resend with the proper Cc and it will then be processed. I
> allowed this to happen before, but that's because I did everything
> manually and not with my scripts. And I'm tired of doing that.

I will do that in the v3.

I will also update the maintainers entry for RTLA and RV, as both are pointing to
linux-trace-devel.

Thanks!
-- Daniel

> 
> Thanks,
> 
> -- Steve
Steven Rostedt May 29, 2023, 8:43 a.m. UTC | #3
On Mon, 29 May 2023 10:38:16 +0200
Daniel Bristot de Oliveira <bristot@kernel.org> wrote:

> On 5/29/23 10:28, Steven Rostedt wrote:
> > Hi Daniel,
> > 
> > Could you make sure to Cc linux-trace-kernel@vger.kernel.org and not
> > linux-trace-devel. The former is for any patch that goes into the
> > kernel repo, the later is for the tracing libraries (like libtracefs).
> > The reason why this matters is that the patchwork that is associated to
> > the Linux kernel tree will not get these (and I will not work on them
> > when I'm working on kernel patches). But it will go into the 
> > patchwork for the libraries (and never be processed by the patchwork
> > infrastructure), and I will likely not work on them, because when I
> > look at the library patchwork, I ignore anything that goes into the
> > kernel.  
> 
> Sure, I will do that. IIRC, we agreed that we would use linux-trace-devel for
> rtla because it is a user-space tool. But I agree with you, as they are patches
> going to the kernel repo, linux-trace-kernel is a better place. It is easier to
> myself too... :-).

I think we agreed on that because linux-trace-kernel didn't exist yet ;-)

> 
> > 
> > Perhaps resend with the proper Cc and it will then be processed. I
> > allowed this to happen before, but that's because I did everything
> > manually and not with my scripts. And I'm tired of doing that.  
> 
> I will do that in the v3.
> 
> I will also update the maintainers entry for RTLA and RV, as both are pointing to
> linux-trace-devel.

I already sent the patch!

-- Steve