On Thu, Jul 14, 2016 at 2:55 AM, Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com> wrote: > Hello, > > On (07/13/16 08:39), Viresh Kumar wrote: > [..] >> Maybe not, as this can still lead to the original bug we were all >> chasing. This may hog some other CPU if we are doing excessive >> printing in suspend :( > > excessive printing is just part of the problem here. if we cab cond_resched() > in console_unlock() (IOW, we execute console_unlock() with preemption and > interrupts enabled) then everything must be ok, and *from printing POV* there > is no difference whether it's printk_kthread or anything else in this case. > the difference jumps in when original console_unlock() is executed with > preemption/irq disabled, then offloading it to schedulable printk_kthread is > the right thing. > >> suspend_console() is called quite early, so for example in my case we >> do lots of printing during suspend (not from the suspend thread, but >> an IRQ handled by the USB subsystem, which removes a bus with help of >> some other thread probably). > > a silly question -- can we suspend consoles later?
Not really and I'm not sure how that would help?
