Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191008220824.7911-1-viktor.rosendahl@gmail.com>
 <20191008220824.7911-5-viktor.rosendahl@gmail.com> <20191009141114.GC143258@google.com>
 <CAPQh3wP93yF4R4LOabmBf8zqTgM7ZVT=_eZRPwgq5WKEESjnyw@mail.gmail.com> <20191009140804.74d9ab1f@gandalf.local.home>
In-Reply-To: <20191009140804.74d9ab1f@gandalf.local.home>
From:   Viktor Rosendahl <viktor.rosendahl@gmail.com>
Date:   Thu, 10 Oct 2019 09:57:31 +0200
Message-ID: <CAPQh3wO1zvwQf0zmb9_ro1spUo+CCxJFCgB2aQJWVW8KZoXQdA@mail.gmail.com>
Subject: Re: [PATCH v8 4/4] ftrace: Add an option for tracing console latencies
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Den ons 9 okt. 2019 kl 20:08 skrev Steven Rostedt <rostedt@goodmis.org>:
>
> On Wed, 9 Oct 2019 16:51:07 +0200
> Viktor Rosendahl <viktor.rosendahl@gmail.com> wrote:
>
> > Apologies, I should have replied there but I have been a bit busy the
> > last few days with other topics, and I felt a bit indecisive about
> > that point, so I just sloppily addressed the issue in the cover letter
> > of this new series:
> >
> > "I have retained the fourth patch, although it was suggested that is becoming
> > obsolete soon. I have retained it only because I do not know the status of
> > the code that will make it obsolete. It's the last patch of the series and
> > if there indeed is some code that will remove the latency issues from the
> > printk code, then of course it makes sense to drop it. The first three patches
> > will work without it."
> >
> > I thought that, since it's the last in the series, it would be
> > possible for maintainers to just take the first three if the last one
> > is not wanted.
> >
> > For me it solves a rather important problem though, so if the code
> > that will make it obsolete isn't available for some time, then perhaps
> > it should be considered as a temporary solution.
> >
> > Of course, if there is a commitment to never remove any knobs from
> > /sys/kernel/debug/tracing/trace_options, then I can easily understand
> > that it's not wanted as a temporary fix.
>
> There isn't quite a commitment to not remove knobs, but if a tool
> starts relying on a knob, then, the answer is yes there is :-p
>
> As this will hopefully become something we don't worry about in the
> future, I would rather have this be a kernel command line option. This
> way, it wont be something that tools can really check for.
>
> If you add a trace_console_latency option to the kernel command line,
> we can enable it that way. And then when it becomes obsolete, we can
> simply remove it, without breaking any tools.
>
> Would that work for you?
>

Sounds good to me. I will try to adjust the patch accordingly within a few days.

best regards,

Viktor

> -- Steve