Hi Sebastian, On Thursday, February 25, 2021 12:38 AM, Sebastian Siewior wrote: > > 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? Sure, let me add some trace events to collect more info. Regards, Ran
