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
