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