Printk Cleanups Ready For Linux 6.6 - Stepping Towards Threaded/Atomic Console Printing

[phoronix]

Phoronix: Printk Cleanups Ready For Linux 6.6 - Stepping Towards Threaded/Atomic Console Printing

A set of printk clean-ups were sent in today for the Linux 6.6 merge window. These clean-ups are important as they are a stepping stone towards the threaded / atomic console printing and in turn that is the last major blocker before the real-time (PREEMPT_RT) support can finally be upstreamed in the kernel...

https://www.phoronix.com/news/Linux-6.6-printk

[skeevy420]

Michael

Today's printk pull has the code clena-ups,

Speaking of which

[caligula]

Does this change make the rt patchset any smaller?

[wertigon]

Does this change make the rt patchset any smaller?

Might remove two or three patches, yes. This URL should give you an answer in a few weeks, results are not in yet:

https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=linux-6.6.y-rt-patches

If I am reading this correctly, the following patches will be eliminated by this:

0001-kdb-do-not-assume-write-callback-available.patch
0003-printk-Consolidate-console-deferred-printing.patch
0004-printk-Add-per-console-suspended-state.patch

It is possible more will come. I hope this means next year LTS will have a PREEMPT_RT inclusion, I think it may be too late to make 6.7.0 the LTS kernel but I could be wrong.

[stormcrow]

It is possible more will come. I hope this means next year LTS will have a PREEMPT_RT inclusion...

Maybe. Yet, I cringe at the flood of people when it hits preliminary release from Linus' tree flock to support and Linux-centric tech news sites complaining that the "real time" kernel broke their game, or it screws up compile times or something entirely not what PREEMPT_RT is for.

[timofonic]

I really hope PREEMPT_RT gets totally merged in mainline before 6.8.

Please make it happen!

[EphemeralEft]

Maybe. Yet, I cringe at the flood of people when it hits preliminary release from Linus' tree flock to support and Linux-centric tech news sites complaining that the "real time" kernel broke their game, or it screws up compile times or something entirely not what PREEMPT_RT is for.

You clearly don't understand. When I click the email button, I want to see my emails now.

[rogerx]

You clearly don't understand. When I click the email button, I want to see my emails now.

Try clicking the Email button slower?

[EphemeralEft]

Try clicking the Email button slower?

The problem is that the click happens all at once, regardless of how slowly I push it.

[wertigon]

Maybe. Yet, I cringe at the flood of people when it hits preliminary release from Linus' tree flock to support and Linux-centric tech news sites complaining that the "real time" kernel broke their game, or it screws up compile times or something entirely not what PREEMPT_RT is for.

Oh, I am TOTALLY with you there. I think the biggest problem here is the name. "Real Time" indicates it happens NOW. Any developer worth their salt knows that nothing can happen instantly, there is always delay (latency). General computing schedulers are designed for the lowest average latency and the so called Real Time is designed for lowest guaranteed latency.

I think personally we should stop using the term Real Time alltogether and instead use "guaranteed latency", but that's just me.