From: Joel Fernandes <joel@joelfernandes.org>
To: Viktor Rosendahl <viktor.rosendahl@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] ftrace: Implement fs notification for preempt/irqsoff tracers
Date: Sat, 4 May 2019 12:47:10 -0400 [thread overview]
Message-ID: <20190504164710.GA55790@google.com> (raw)
In-Reply-To: <20190501203650.29548-2-viktor.rosendahl@gmail.com>
On Wed, May 01, 2019 at 10:36:47PM +0200, Viktor Rosendahl wrote:
> This patch implements the feature that the trace file, e.g.
> /sys/kernel/debug/tracing/trace will receive notifications through
> the fsnotify framework when a new trace is available.
>
> This makes it possible to implement a user space program that can,
> with equal probability, obtain traces of latencies that occur
> immediately after each other in spite of the fact that the
> preempt/irqsoff tracers operate in overwrite mode.
>
> Signed-off-by: Viktor Rosendahl <viktor.rosendahl@gmail.com>
I agree with the general idea, but I don't really like how it is done in the
patch.
We do have a notification mechanism already in the form of trace_pipe. Can we
not improve that in some way to be notified of a new trace data? In theory,
the trace_pipe does fit into the description in the documentation: "Reads
from this file will block until new data is retrieved"
More comment below:
> ---
> kernel/trace/Kconfig | 10 ++++++++++
> kernel/trace/trace.c | 31 +++++++++++++++++++++++++++++--
> kernel/trace/trace.h | 5 +++++
> kernel/trace/trace_irqsoff.c | 35 +++++++++++++++++++++++++++++++++++
> 4 files changed, 79 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index 8bd1d6d001d7..35e5fd3224f6 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -234,6 +234,16 @@ config PREEMPT_TRACER
> enabled. This option and the irqs-off timing option can be
> used together or separately.)
>
> + config PREEMPTIRQ_FSNOTIFY
> + bool "Generate fsnotify events for the latency tracers"
> + default n
> + depends on (IRQSOFF_TRACER || PREEMPT_TRACER) && FSNOTIFY
> + help
> + This option will enable the generation of fsnotify events for the
> + trace file. This makes it possible for userspace to be notified about
> + modification of /sys/kernel/debug/tracing/trace through the inotify
> + interface.
Does this have to be a CONFIG option? If prefer if the code automatically
does the notification and it is always enabled. I don't see any drawbacks of
that.
> +
> config SCHED_TRACER
> bool "Scheduling Latency Tracer"
> select GENERIC_TRACER
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index ca1ee656d6d8..ebefb8d4e072 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -44,6 +44,8 @@
> #include <linux/trace.h>
> #include <linux/sched/clock.h>
> #include <linux/sched/rt.h>
> +#include <linux/fsnotify.h>
> +#include <linux/workqueue.h>
>
> #include "trace.h"
> #include "trace_output.h"
> @@ -8191,6 +8193,32 @@ static __init void create_trace_instances(struct dentry *d_tracer)
> return;
> }
>
> +#ifdef CONFIG_PREEMPTIRQ_FSNOTIFY
> +
> +static void trace_notify_workfn(struct work_struct *work)
[snip]
I prefer if this facility is available to other tracers as well such as
the wakeup tracer which is similar in output (check
Documentation/trace/ftrace.txt). I believe this should be a generic trace
facility, and not tracer specific.
thanks,
- Joel
next prev parent reply other threads:[~2019-05-04 16:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-01 20:36 [PATCH v2 0/4] Some new features for the preempt/irqsoff tracers Viktor Rosendahl
2019-05-01 20:36 ` [PATCH v2 1/4] ftrace: Implement fs notification for " Viktor Rosendahl
2019-05-04 16:47 ` Joel Fernandes [this message]
2019-05-05 19:43 ` Steven Rostedt
2019-05-05 22:39 ` Viktor Rosendahl
2019-05-05 23:01 ` Steven Rostedt
2019-05-05 23:54 ` Viktor Rosendahl
2019-05-06 14:00 ` Joel Fernandes
2019-05-01 20:36 ` [PATCH v2 2/4] preemptirq_delay_test: Add the burst feature and a sysfs trigger Viktor Rosendahl
2019-05-01 20:36 ` [PATCH v2 3/4] Add the latency-collector to tools Viktor Rosendahl
2019-05-01 20:36 ` [PATCH v2 4/4] ftrace: Add an option for tracing console latencies Viktor Rosendahl
2019-05-02 1:38 ` Steven Rostedt
2019-05-02 18:37 ` Viktor Rosendahl
2019-05-02 21:12 ` Steven Rostedt
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=20190504164710.GA55790@google.com \
--to=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=viktor.rosendahl@gmail.com \
/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: link
Be 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.