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.. -- viresh
