On Mon 2019-03-11 09:18:26, Sebastian Andrzej Siewior wrote: > On 2019-03-11 11:46:00 [+0900], Sergey Senozhatsky wrote: > > On (03/08/19 15:02), Sebastian Andrzej Siewior wrote: > > > On 2019-02-12 15:30:03 [+0100], John Ogness wrote: > > > > > > you removed the whole `irq_work' thing. You can also remove the include > > > for linux/irq_work.h. > > > > It may be too early to remove the whole `irq_work' thing. > > printk()->call_console_driver() should take console_sem > > lock. > > I would be _very_ glad to see that irq_work thingy gone. I just stumbled > upon this irq_work and cursed a little while doing other things. Have you seen stalls causes by the irq work? Or was it just glancing over the printk code? > Checking John's series and seeing that it was gone, was a relief. > Printing the whole thing in irq context does not look sane. printing the > import things right away and printing the remaining things later in > kthread looks good to me. The irq_work was originally added to handle messages from the scheduler by printk_deferred(). It was later used also to handle messages from NMI and printk recursion. It means that the use is pretty limited. It is more reliable than a kthread, especially when the scheduler is reporting problems. IMHO, it is a reasonable solution as long as the amount of messages is low. The real time kernel is another story but it has special handling in many other situations. That said, the kthread might still make sense as a fallback. It would be nice to have a hard limit for handling messages in irq context. Best Regards, Petr
