Re: [Query] Preemption (hogging) of the work handler

[Sergey Senozhatsky <sergey.senozhatsky@gmail.com>]

Hello,

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.

Thanks, Petr.


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) ?

	-ss

> Well, we might do the best effort when no_console_suspend is enabled.
> 
> 
> Best Regards,
> Petr
>