Re: [PATCH] rt: cpufreq: Fix cpu hotplug hang

[Sebastian Siewior <bigeasy@linutronix.de>]

On 2021-02-23 08:43:08 [+0530], Viresh Kumar wrote:
> On 23-02-21, 02:26, Ran Wang wrote:
> > On Monday, February 22, 2021 10:01 PM, Sebastian Siewior wrote:
> > > On 2021-02-19 16:44:20 [+0800], Ran Wang wrote:
> > > > When selecting PREEMPT_RT, cpufreq_driver->stop_cpu(policy) might got
> > > > stuck due to irq_work_sync() pending for work on lazy_list. That’s
> > > > because lazy_list may have no chance to be served in softirq context
> > > > sometimes. Below is one of scenarios that was captured:
> > > >
> > > > ...
> > > > ret_from_fork
> > > >  kthread
> > > >   smpboot_thread_fn
> > > >    cpuhp_thread_fun
> > > >     cpuhp_invoke_callback: state: 193
> > > >      cpuhp_cpufreq_online
> > > >       cpufreq_online
> > > >        cpufreq_driver->stop_cpu(policy);
> > > >         cpufreq_dbs_governor_stop
> > > >          sugov_stop  // kernel/sched/cpufreq_schedutil.c
> > > >           irq_work_sync(&sg_policy->irq_work);
> > > >
> > > > This is observed on LX2160ARDB (16 A72 cores) with cpufreq governor of
> > > > ‘schedutil’ or ‘ondemand’.
> > > 
> > > While staring at it, why do we invoke schedule_work_on() and
> > > kthread_queue_work() from inside irq_work() instead invoking it directly? It raises an interrupt in which it kicks a user thread.
> > > Couldn't we do it without irq_work?
> 
> Because we reach there from scheduler's context, which must be
> hard-irq context..

Oha. Too bad.
Ran, any chance to figure out why the softirq can not be served?
ksoftirqd and the timer should be up.
Any numbers on how often that is irq_work is scheduled?

Sebastian