[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230529042839.5d4af427@rorschach.local.home>
Date: Mon, 29 May 2023 04:28:39 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Daniel Bristot de Oliveira <bristot@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-devel@...r.kernel.org,
linux-doc@...r.kernel.org, Juri Lelli <juri.lelli@...hat.com>,
William White <chwhite@...hat.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH V2 0/9] rtla improvements
Hi Daniel,
Could you make sure to Cc linux-trace-kernel@...r.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@...nel.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
>
Powered by blists - more mailing lists