On 2025-01-08 17:06:06 [+0800], Hou Tao wrote: > Hi, Hi, > On 1/8/2025 3:29 PM, Sebastian Andrzej Siewior wrote: > > On 2025-01-08 09:24:02 [+0800], Hou Tao wrote: > >> @Sebastian > >> Is it possible that softirq_expiry_lock is changed to a raw-spin-lock > >> instead ? > > No. The point is to PI-boost the timer-task by the task that is > > canceling the timer. This is possible if the timer-task got preempted by > > the canceling task - both can't be migrated to another CPU and if the > > canceling task has higher priority then it will continue to spin and > > live lock the system. > > Making the expire lock raw would also force every timer to run with > > disabled interrupts which would not allow to acquire any spinlock_t > > locks. > > Thanks for the explanation. However I still can not understand why > making the expire lock raw will force every timer to run with disabled > interrupt. I'm sorry. Not disabled interrupts but preemption. hrtimer_run_softirq() acquires the lock via hrtimer_cpu_base_lock_expiry() and holds it while during __hrtimer_run_queues() -> __run_hrtimer(). Only hrtimer_cpu_base::lock is dropped before the timer is invoked. If preemption is disabled you can not acquire a spinlock_t. > In my simple understanding, hrtimer_cpu_base_lock_expiry() > doesn't disable the irq. Do you mean if change the expire lock to raw, > it also needs to disable the irq to prevent something from happening, > right ? No, see the above, it should clear things up. > Also does the raw spinlock have the PI-boost functionality ? No. Blocking on a raw_spinlock_t means to spin until it is its turn to acquire the lock. The spinlock_t becomes a rt_mutex on PREEMPT_RT and blocking on a lock means: give current priority to lock owner (= Priority Inheritance) + go to sleep until lock becomes available. Sebastian
