Linux 5.19's Printk To Offload Messages To Per-Console KThreads
The Linux kernel's printk() function for printing messages to the kernel log continues to be improved upon in 2022.
Over the past few years there has been an effort to improve Linux's printk with various refinements to make it more robust and reliable for this widely-used kernel function. The latest fruits of that work have been about getting consoles running at full-speed in creating a thread for each registered console. With Linux 5.19 that material is landing.
Sent in for Linux 5.19 is the support for offload writing of printk() messages on consoles to per-console KThreads. Petr Mladek of SUSE explained:
See this pull request for more details and hooray for continuing to improve printk() in 2022.
Over the past few years there has been an effort to improve Linux's printk with various refinements to make it more robust and reliable for this widely-used kernel function. The latest fruits of that work have been about getting consoles running at full-speed in creating a thread for each registered console. With Linux 5.19 that material is landing.
Sent in for Linux 5.19 is the support for offload writing of printk() messages on consoles to per-console KThreads. Petr Mladek of SUSE explained:
Offload writing printk() messages on consoles to per-console kthreads.
It prevents soft-lockups when an extensive amount of messages is printed. It was observed, for example, during boot of large systems with a lot of peripherals like disks or network interfaces.
It prevents live-lockups that were observed, for example, when messages about allocation failures were reported and a CPU handled consoles instead of reclaiming the memory. It was hard to solve even with rate limiting because it would need to take into account the amount of messages and the speed of all consoles.
It is a must to have for real time. Otherwise, any printk() might break latency guarantees.
The per-console kthreads allow to handle each console on its own speed. Slow consoles do not longer slow down faster ones. And printk() does not longer unpredictably slows down various code paths.
There are situations when the kthreads are either not available or not reliable, for example, early boot, suspend, or panic. In these situations, printk() uses the legacy mode and tries to handle consoles immediately.
See this pull request for more details and hooray for continuing to improve printk() in 2022.
1 Comment