Messages in this thread | | | Date | Tue, 12 Jul 2016 23:03:00 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [Query] Preemption (hogging) of the work handler |
| |
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 >
| |