lkml.org 
[lkml]   [2022]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] printk for 5.20

* 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

\
 
 \ /
  Last update: 2022-08-03 19:09    [W:0.045 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site