On (02/13/19 15:43), John Ogness wrote: > On 2019-02-13, Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> 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)? If there are setups which can be fully !atomic (in terms of console output) then we, essentially, have a fully preemptible kthread printk implementation. > Because you have already done so much work and experimentation with > printk-kthreads, I feel like many of your comments are related to your > kthread work in this area. Really the big design change I make with my > printk-kthread is that it is only for non-critical messages. For > anything critical, users should rely on an emergency console. Fair point. Well maybe my printk-kthread comments are not utterly unreasonable, but who knows :) -ss
