Hi, On 1/8/2025 5:16 PM, Sebastian Andrzej Siewior wrote: > 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. Thanks for the detailed explanation. I got it now. > > Sebastian
