Messages in this thread | | | Date | Thu, 14 Jul 2016 14:55:49 -0700 | From | Viresh Kumar <> | Subject | Re: [Query] Preemption (hogging) of the work handler |
| |
On 14-07-16, 09:55, Sergey Senozhatsky wrote: > excessive printing is just part of the problem here. if we cab cond_resched() > part of suspend/hibernation is cpu_down(), which lands in console_cpu_notify(), > that does synchronous printing for every CPU taken down: > > static int console_cpu_notify(struct notifier_block *self, > unsigned long action, void *hcpu) > { > switch (action) { > case CPU_ONLINE: > case CPU_DEAD: > case CPU_DOWN_FAILED: > case CPU_UP_CANCELED: > console_lock(); > console_unlock(); > ^^^^^^^^^^^^^^ > } > return NOTIFY_OK; > } > > console_unlock() is synchronous (I posted a very early draft patch that makes > it asynchronous, but that's a future work). so if there is a ton of printk()-s, > then console_unlock() will print it, 100% guaranteed. even if printk_kthread > is doing the printing job at the moment, cpu down path will wait for it to > stop, lock the console semaphore, and got to console_unlock() printing loop.
Hmm...
> in printk that you have posted, that will happen not only for CPU_DEAD,
It doesn't happen for CPU_DEAD right now as CONFIG_CONSOLE_FLUSH_ON_HOTPLUG isn't enabled in my setup.
> but for CPU_DYING as well (possibly, there is a /* invoked with preemption > disabled, so defer */ comment, so may be you never endup doing direct > printk there, but then you schedule a console_unlock() work).
-- viresh
| |