Hello Rafael, 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? Could you please help comment on above question (I just follow CPU Freq scaling framework, can't tell why) Thank you very much. Regards, Ran
