Messages in this thread | | | Date | Fri, 30 Jun 2017 10:45:54 -0400 | From | Steven Rostedt <> | Subject | Re: [RFC][PATCHv3 2/5] printk: introduce printing kernel thread |
| |
On Fri, 30 Jun 2017 23:28:51 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> I guess the question was, a knob that would determine what happens after > current wakes up printk_kthread -- does it stay in console_unlock() and > wait for new console_sem owner, printing the messages in the meantime, > or goes all in and expects printk_kthread or anything else to lock > console_sem at some point and flush the remaining messages. is that > correct? we can do this (well, I'm absolutely not in position to say > "we can't do this" :) ). I guess the sort of a problem we have now is > that we can't guarantee that wake_up() will actually wake_up printk_kthread. > but if user requests it, then well... it might be easier to adjust watchdog > timeout value ;) just kidding. or may be I misunderstood your question.
Actually, what I was thinking of was just setting a hard limit at how much printk() can write without pushing it off to a helper thread. Kind of like how softirq works. If there's too much work, it then pushes off the rest to ksoftirqd.
If we have a kprintd, have a knob that says how much printk can write under console_lock, and after it hits a limit (default being no limit), then to simply wake up kprintd to do the rest. This should allow those that care to limit how much time printk can stop a CPU by, with the knowledge that if the kernel were to crash, there's a good chance that the necessary debug info will not be printed.
Now as I have said, the default would be to keep things as is, and let printk take up as much of the CPU it needs till it gets all the pending prints out.
I would also like (in my wish list), a mechanism, that when an oops in progress happens, to set an emergency flag. If something already has console_lock, then we can let it do what it does today, and have the critical thread write its data to the logbuf, and let the current printer hopefully output it (I think that's what we do today). But if there's no holder of console lock, the critical thread takes control and dumps the buffer to get everything out. Once that emergency flag is set, there will be no more offloading. All prints will be in critical mode, and try to get the data out if possible.
While I'm giving you my Christmas list, I would also like a way to have an NMI safe lock in printk (like Peter Zijlstra and I have patches for with early-printk). Which checks if the current CPU owns the spin lock, and if it doesn't it is safe to take the lock even in NMI mode. But if the current CPU has the lock, then the NMI handle does the printing without locking, not caring if it screws up the thread that is currently printing.
Of course we need to be careful about various consoles that have their own locks. Maybe make an NMI lock primitive that all consoles use?
This is just wishful thinking, but hopefully we can come up with something that can solve all issues reasonably.
-- Steve
| |