On (09/06/19 16:55), Petr Mladek wrote: > > I think we can queue significantly much less irq_work-s from printk(). > > > > Petr, Steven, what do you think? > > > > Something like this. Call wake_up_interruptible(), switch to > > wake_up_klogd() only when called from sched code. > > Replacing irq_work_queue() with wake_up_interruptible() looks > dangerous to me. > > As a result, all "normal" printk() calls from the scheduler > code will deadlock. There is almost always a userspace > logger registered. I don't see why all printk()-s should deadlock. A "normal" printk() call will deadlock only when scheduler calls "normal" printk() under rq or pi locks. But this is illegal anyway, because console_sem up() calls wake_up_process() - the same function wake_up_interruptible() calls. IOW "normal" printk() calls from scheduler end up in scheduler, via console_sem->sched chain. We already execute wake_up_process()->try_to_wake_up() in printk(), even when a non-LOGLEVEL_SCHED printk() comes from scheduler. What am I missing something? -ss
