RCU :)
On Fri, Dec 08 2023 at 10:42, Peter Zijlstra wrote:
> On Fri, Dec 08, 2023 at 09:28:23AM +0100, Thomas Gleixner wrote:
>> So the task is not enqueued on a dead runqueue. The problem is the
>> bandwidth timer which is started with:
>>
>> hrtimer_start_expires(&rt_b->rt_period_timer, HRTIMER_MODE_ABS_PINNED_HARD);
>>
>> PINNED means it is forced to be queued on the current CPU, which is
>> already marked dead and offline.
>
> Durr, so somewhere in 2015 I did that PINNED thing and I can't for the
> life of me remember why exactly.
>
> I *think* the thinking was that we want that timer to stay local to the
> bandwidth group, and pinned is the only locality option we have.
>
> But ywah, it makes more sense to schedule it on the CPU where the task
> goes, but also, hrtimer doesn't have a great steering API either.
>
> Just rip this code up, it's all crap anyway. Remove the PINNED, or force
> migrate to the task's CPU whatever.
So?
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 6aaf0a3..2b24871 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -117,8 +117,7 @@ static inline void do_start_rt_bandwidth(struct rt_bandwidth *rt_b)
* to update the period.
*/
hrtimer_forward_now(&rt_b->rt_period_timer, ns_to_ktime(0));
- hrtimer_start_expires(&rt_b->rt_period_timer,
- HRTIMER_MODE_ABS_PINNED_HARD);
+ hrtimer_start_expires(&rt_b->rt_period_timer, HRTIMER_MODE_ABS_HARD);
}
raw_spin_unlock(&rt_b->rt_runtime_lock);
}
