Messages in this thread | | | Date | Wed, 3 Aug 2022 19:08:51 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |