tree 5f839cc21bff45b950adaa523fbe7d8b03a3bd6f
parent 2cc14f52aeb78ce3f29677c2de1f06c0e91471ab
author Thomas Gleixner <tglx@linutronix.de> 1702035982 +0100
committer Paul E. McKenney <paulmck@kernel.org> 1702051654 -0800

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>