Messages in this thread | | | From | John Ogness <> | Subject | Re: [RFC PATCH v1 00/25] printk: new implementation | Date | Thu, 07 Mar 2019 10:53:48 +0100 |
| |
On 2019-03-04, Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote: >>>> - A dedicated kernel thread is created for printing to all consoles >>>> in a fully preemptible context. >>> >>> How do you handle sysrq-<foo> printouts on systems which can't >>> schedule printk-kthread? >> >> If those sysrq printouts are at the emergency loglevel (which most >> are), then they are printed immediately to the emergency >> consoles. This has already proved useful for our own kernel debugging >> work. For example, currently sysrq-z for very large traces result in >> messages being dropped because of printk buffer overflows. But with >> the emergency console we always see the full trace buffer. > > Are we sure that all systems will always have ->atomic console(-s) > enabled? Is it possible to convert all console drivers to ->atomic? > fbcon, for instance (with scrolling and font scaling, etc)?
No, I am not sure if we can convert all console drivers to atomic consoles. But I think if we don't have to fear disturbing the system, the possibilities for such an implementation are greater.
> If there are setups which can be fully !atomic (in terms of console > output) then we, essentially, have a fully preemptible kthread printk > implementation.
Correct. I've mentioned in another response[0] some ideas about what could be done to aid this.
I understand that fully preemptible kthread printing is unacceptable for you. Since all current console drivers are already irq safe, I'm wondering if using irq_work to handle the emergency printing for console drivers without write_atomic() would help. (If the printk caller is in a context that write() supports, then write() could be called directly.) This would also demand that the irq-safe requirements for write() are not relaxed. The printk-kthread might still be faster than irq_work, but it might increase reliability if an irq_work is triggered as an extra precaution.
John Ogness
[0] https://lkml.kernel.org/r/87o96p9gtx.fsf@linutronix.de
| |