[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190514125103.64d778d6@oasis.local.home>
Date: Tue, 14 May 2019 12:51:03 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Viktor Rosendahl <viktor.rosendahl@...il.com>
Cc: Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH v3 0/4] Some new features for the latency tracers
On Mon, 13 May 2019 23:50:04 +0200
Viktor Rosendahl <viktor.rosendahl@...il.com> wrote:
> Hello all,
Hi Viktor,
Note, as the merge window is open and I'm also currently at a
conference, it may be a while before I can take a look at this. If you
don't hear something from me in 10 days, feel free to send me a ping.
-- Steve
>
> Changes in v3:
> - [PATCH 1/4]:
> * I have generalized this to send the fsnotify() notifications for all
> tracers that use tracing_max_latency.
>
> * There are large additions of code to prevent queue_work() from being
> called while we are in __schedule() or do_idle(). This was a bug also
> in the previous version but had gone unnoticed. It became very visible
> when I tried to make it work with the wakeup tracers because they are
> always invoked from the sched_switch tracepoint.
>
> * The fsnotify notification is issued for tracing_max_latency, not trace.
>
> * I got rid of the kernel config option. The facility is always compiled
> when CONFIG_FSNOTIFY is enabled and any of the latency tracers are
> enabled.
>
> - [PATCH 2/4]:
> * No significant changes.
>
> - [PATCH 3/4]:
> * The latency-collector help messages have been tuned to the fact that it
> can be used also with wakeup and hwlat tracers.
>
> * I increased the size of the buffer for reading from
> /sys/kernel/debug/tracing/trace.
>
> * Adapted it to monitor tracing_max_latency instead of trace
>
> - [PATCH 4/4]:
> * I converted this from a kernel config option to a trace config option
> that can be changed at runtime.
>
>
Powered by blists - more mailing lists