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 v7 4/4] ftrace: Add an option for tracing console latencies
Date: Thu, 3 Oct 2019 09:48:09 -0400 [thread overview]
Message-ID: <20191003134809.GD254942@google.com> (raw)
In-Reply-To: <c34eb6e7-18c4-84b5-1fe5-74320dc36a25@gmail.com>
On Thu, Oct 03, 2019 at 12:44:09AM +0200, Viktor Rosendahl wrote:
> On 10/2/19 2:52 AM, Joel Fernandes wrote:
> > On Fri, Sep 20, 2019 at 05:22:19PM +0200, Viktor Rosendahl (BMW) wrote:
> > > This new trace option "console-latency" will enable the latency
> > > tracers to trace the console latencies. Previously this has always been
> > > implicitely disabled. I guess this is because they are considered
> > > to be well known and unavoidable.
> > >
> > > However, for some organizations it may nevertheless be desirable to
> > > trace them. Basically, we want to be able to tell that there are
> > > latencies in the system under test because someone has incorrectly
> > > enabled the serial console.
> > >
> > > Signed-off-by: Viktor Rosendahl (BMW) <viktor.rosendahl@gmail.com>
> > > ---
> > > include/linux/irqflags.h | 22 ++++++++++++++++++++++
> > > kernel/printk/printk.c | 6 ++++--
> > > kernel/trace/trace.h | 1 +
> > > kernel/trace/trace_irqsoff.c | 12 ++++++++++++
> > > 4 files changed, 39 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
> > > index 21619c92c377..3de891723331 100644
> > > --- a/include/linux/irqflags.h
> > > +++ b/include/linux/irqflags.h
> > > @@ -13,6 +13,7 @@
> > > #define _LINUX_TRACE_IRQFLAGS_H
> > > #include <linux/typecheck.h>
> > > +#include <linux/types.h>
> > > #include <asm/irqflags.h>
> > > /* Currently trace_softirqs_on/off is used only by lockdep */
> > > @@ -68,9 +69,30 @@ do { \
> > > defined(CONFIG_PREEMPT_TRACER)
> > > extern void stop_critical_timings(void);
> > > extern void start_critical_timings(void);
> > > + extern bool console_tracing_disabled(void);
> > > +
> > > +# define console_stop_critical_timings(flag) \
> > > + do { \
> > > + typecheck(bool, flag); \
> > > + flag = console_tracing_disabled(); \
> > > + if (flag) \
> > > + stop_critical_timings(); \
> > > + } while (0)
> > > +
> > > +# define console_start_critical_timings(flag) \
> > > + do { \
> > > + typecheck(bool, flag); \
> > > + if (flag) \
> > > + start_critical_timings(); \
> > > + } while (0)
> > > +
> > > #else
> > > # define stop_critical_timings() do { } while (0)
> > > # define start_critical_timings() do { } while (0)
> > > +# define console_stop_critical_timings(flag) \
> > > + do { typecheck(bool, flag); } while (0)
> > > +# define console_start_critical_timings(flag) \
> > > + do { typecheck(bool, flag); } while (0)
> > > #endif
> > > /*
> > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > > index 1888f6a3b694..036460a7e4cd 100644
> > > --- a/kernel/printk/printk.c
> > > +++ b/kernel/printk/printk.c
> > > @@ -2359,6 +2359,7 @@ void console_unlock(void)
> > > static char ext_text[CONSOLE_EXT_LOG_MAX];
> > > static char text[LOG_LINE_MAX + PREFIX_MAX];
> > > unsigned long flags;
> > > + bool cflag;
> > > bool do_cond_resched, retry;
> > > if (console_suspended) {
> > > @@ -2459,9 +2460,10 @@ void console_unlock(void)
> > > */
> > > console_lock_spinning_enable();
> > > - stop_critical_timings(); /* don't trace print latency */
> > > + /* don't trace print latency if it's disabled */
> > > + console_stop_critical_timings(cflag);
> > > call_console_drivers(ext_text, ext_len, text, len);
> > > - start_critical_timings();
> > > + console_start_critical_timings(cflag);
> > > if (console_lock_spinning_disable_and_check()) {
> > > printk_safe_exit_irqrestore(flags);
> > > diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> > > index 4913ed1138aa..93a8b82c27e4 100644
> > > --- a/kernel/trace/trace.h
> > > +++ b/kernel/trace/trace.h
> > > @@ -1262,6 +1262,7 @@ extern int trace_get_user(struct trace_parser *parser, const char __user *ubuf,
> > > C(PRINTK_MSGONLY, "printk-msg-only"), \
> > > C(CONTEXT_INFO, "context-info"), /* Print pid/cpu/time */ \
> > > C(LATENCY_FMT, "latency-format"), \
> > > + C(CONSOLE_LATENCY, "console-latency"), \
> > > C(RECORD_CMD, "record-cmd"), \
> > > C(RECORD_TGID, "record-tgid"), \
> > > C(OVERWRITE, "overwrite"), \
> > > diff --git a/kernel/trace/trace_irqsoff.c b/kernel/trace/trace_irqsoff.c
> > > index a745b0cee5d3..bc02be207a7a 100644
> > > --- a/kernel/trace/trace_irqsoff.c
> > > +++ b/kernel/trace/trace_irqsoff.c
> > > @@ -456,6 +456,18 @@ void stop_critical_timings(void)
> > > EXPORT_SYMBOL_GPL(stop_critical_timings);
> > > NOKPROBE_SYMBOL(stop_critical_timings);
> > > +bool console_tracing_disabled(void)
> > > +{
> > > + struct trace_array *tr = irqsoff_trace;
> > > + int pc = preempt_count();
> > > +
> > > + if (!preempt_trace(pc) && !irq_trace())
> > > + return false;
> >
> > Why this condition here? Why not just make the call to
> > stop_critical_timings() dependent on the new flag you are adding? Please
> > explain it more and add some comments.
> >
>
> It is a kind of optimization for the common case, i.e. that the tracer
> is not enabled.
>
> The idea is that if the preemptirqsoff tracing is disabled, then the
> question of whether or not to trace console latencies is moot and by
> telling the caller that it is not disabled, we will prevent the caller
> from making the calls to stop_critical_timings() and
> start_critical_timings(). These calls would only return without doing
> anything if the condition "!preempt_trace(pc) && !irq_trace()" is true,
> since they use the inverse condition "preempt_trace(pc) || irq_trace()"
> to test whether or not they should do anything.
>
> I have to admit that this may be a useless micro optimization that
> makes the code harder to understand and maintain for a benefit that
> is so small that it would be hard to measure.
>
> I feel a bit unsure whether I should try to improve it by adding a
> comment, and perhaps putting the condition into a macro that
> could then also be used by the start/stop_critical_timings() functions,
> or if I should just get rid of the optimization. I guess this console
> code is not a particularly hot code path anyway.
>
> Please let me know what you think.
Oh, I see what you are doing now. I think you can just add a comment on top
of the if block explaining this.
But IIRC the printk code is being rewritten to not have real-time latency
issues, so may be this patch will become obsolete pretty soon?
Unless you really need this patch for your series, I would should just drop it.
thanks,
- Joel
> best regards,
>
> Viktor
>
> > thanks,
> >
> > - Joel
> >
> >
> > > +
> > > + return !(tr->trace_flags & TRACE_ITER_CONSOLE_LATENCY);
> > > +}
> > > +EXPORT_SYMBOL_GPL(console_tracing_disabled);
> > > +
> > > #ifdef CONFIG_FUNCTION_TRACER
> > > static bool function_enabled;
> > > --
> > > 2.17.1
> > >
>
prev parent reply other threads:[~2019-10-03 13:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 15:22 [PATCH v7 0/4] Some new features for the preempt/irqsoff tracers Viktor Rosendahl (BMW)
2019-09-20 15:22 ` [PATCH v7 1/4] ftrace: Implement fs notification for tracing_max_latency Viktor Rosendahl (BMW)
2019-10-02 0:32 ` Joel Fernandes
2019-10-03 10:23 ` Viktor Rosendahl
2019-10-02 15:13 ` Steven Rostedt
2019-10-02 22:04 ` Viktor Rosendahl
2019-10-02 22:50 ` Steven Rostedt
2019-09-20 15:22 ` [PATCH v7 2/4] preemptirq_delay_test: Add the burst feature and a sysfs trigger Viktor Rosendahl (BMW)
2019-10-02 0:43 ` Joel Fernandes
2019-09-20 15:22 ` [PATCH v7 3/4] Add the latency-collector to tools Viktor Rosendahl (BMW)
2019-09-20 15:22 ` [PATCH v7 4/4] ftrace: Add an option for tracing console latencies Viktor Rosendahl (BMW)
2019-10-02 0:52 ` Joel Fernandes
2019-10-02 22:44 ` Viktor Rosendahl
2019-10-03 13:48 ` Joel Fernandes [this message]
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=20191003134809.GD254942@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox