Re: [Query] Preemption (hogging) of the work handler
From: Sergey Senozhatsky
Date: Tue Jul 12 2016 - 10:03:32 EST
On (07/12/16 14:52), Petr Mladek wrote:
> > On (07/11/16 15:35), Viresh Kumar wrote:
> > [..]
> > > Sometimes, the platform doesn't come back after suspend. I have tried
> > > enabling no-console-suspend and the last line it prints is:
> > >
> > > Disabling non-boot CPUs
> I guess that the printk() kthread is not longer scheduled when there
> is only one CPU left.
> > > And nothing after that at all. We have to forcefully reboot the phone
> > > after that. Moving the prints to they synchronous way (using
> > > echo 1 > /sys/module/printk/parameters/synchronous), fixes that issue.
> > hm... I'll take a look.
> We might try to explicitly flush the consoles in suspend_console().
> But I am not sure if we always want to do so because it might take
> a while. Also it need not help if someone already owns the
> console_sem. Note the console_unlock() calls the cond_resched()
> when in safe context.
so, I'm looking at this thing now:
: [ 12.874909] sched: RT throttling activated for rt_rq ffffffc0ac13fcd0 (cpu 0)
: [ 12.874909] potential CPU hogs:
: [ 12.874909] printk (292)
so it's either cond_resched() does not reshed, keeping printk kthread
active, which, however, upsets the sched and triggers throttling (umm, what);
or we, somehow, have `console_may_schedule == 0' in this final console_unlock(),
so cond_resched() never happens.
I'm looking at mainline 3.10, tho.
Viresh, can you verify if we can do cond_resched() from console_unlock()
(console_may_schedule != 0) ?
> Well, we might do the best effort when no_console_suspend is enabled.
> Best Regards,