Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Wed, 3 Aug 2022 19:08:51 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        John Ogness <john.ogness@linutronix.de>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Thomas Gleixner <tglx@linutronix.de>, Jan Kara <jack@suse.cz>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] printk for 5.20
Message-ID: <YuqroyYLQua8y+L3@gmail.com>
References: <YufsTLpighCI7qSf@alley>
 <CAHk-=wie+VC-R5=Hm=Vrg5PLrJxb1XiV67Efx-9Cr1fBKCWHTQ@mail.gmail.com>
 <YuqXkCZEfsSKoIX6@alley>
 <CAHk-=wj0umHOtL1TB_7Tvinoqhxz6BnL-jEC0eQfVihHOmbWjw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wj0umHOtL1TB_7Tvinoqhxz6BnL-jEC0eQfVihHOmbWjw@mail.gmail.com>
Precedence: bulk


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, Aug 3, 2022 at 8:43 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > On Tue 2022-08-02 20:19:34, Linus Torvalds wrote:
> > > And printing messages to a console is not some "oh, we'll just stop
> > > doing that because you asked for PREEMPT_RT".
> >
> > My thinking was that PREEMPT_RT was used only by some rather small
> > community that was very well aware of the upstream status. I kind of
> > though that this was their choice.
> 
> Oh, I agree that it probably is a pretty small community.
> 
> And I also think that people who are really into RT are basically
> always going to have extra patches anyway - I think the bulk of the
> core stuff has made it upstream, but not *all* has made it.
> 
> And the "real RT" people tend to also have long lead times - it's not
> just about "we need guaranteed latency", it also tends to be about
> "our hardware is special and stays around for years" too - and likely
> wouldn't ever really use upstream kernels directly anyway.
> 
> In fact, I don't think anybody can currently even enable PREEMPT_RT in
> an upstream kernel anyway without extra patches. Much of the RT
> infrastructure has been merged, but some of the grottier parts are
> literally just "to make it easier to maintain the real external
> patch".
> 
> So I agree with you that in reality it probably wouldn't really affect
> very many people, if any.
> 
> I suspect the most immediate effect would literally be people who want
> to experiment with it, "just because".
> 
> Not the serious RT users who probably have special hardware anyway and
> are likely to also have special debug interfaces (exactly _because_
> they have special latency concerns).

As a side note, Red Hat is productizing -rt, and in general lots of systems 
with non-broken hardware will work mostly fine under -rt. For the really 
hairy hard-realtime usecases a lot of verification is done - often as part 
of the project.

With all the 'edge computing' usecases arising & the automotive industry 
getting much more software-intense, I think it's a safe policy to make -rt 
less special & adhere to the same quality and upstream maintenance 
standards as regular Linux distributions.

In a few years PREEMPT_RT won't be all that special anymore, and working 
consoles are very much part of a usable product.

> So that's why I'd suspect that the actual effect would be on people who 
> just want to tinker with it, and download the necessary RT patches and 
> set up some data acquisition station for their own use or whatever.
> 
> But thinking some more about it, even the "serious RT" people almost 
> certainly don't really want some kind of static "disable it all". Not 
> even if it was a separate Kconfig question like I suggested.
> 
> You'd most likely want it to be dynamic, because things like "log to 
> console" is different at bootup when the system hasn't started yet - you 
> can't really have realtime response when your hardware hasn't even 
> initialized yet - and when things are actually running.
> 
> So I think even then you really just want a "turn off console logging" 
> dynamic flag, not a Kconfig option.
> 
> Which I think we already have, in the form of log levels. No?

Yeah:

  CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
  CONFIG_CONSOLE_LOGLEVEL_QUIET=4

What we could do is to set the default console loglevel really low by on 
PREEMPT_RT - say to 1. Serious crashes would still show up - but random 
console chatter wouldn't.

Thanks,

	Ingo