Re: [RFC] Repeated rto_push_irq_work_func() invocation.

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2024-10-02 11:19:20 [-0400], Steven Rostedt wrote:
> > +rcu_read_lock() but yes. This would be one part. You need to check if
> 
> Yeah, preempt_disable() is pretty much equivalent today to rcu_read_lock(),
> as synchronize_rcu() and synchronize_sched() have been merged into one.

I know but…

> > the task on pull-list has lower priority than the current task on rq.
> > This would be need to be moved to somewhere in schedule() probably after
> > pick_next_task().
> 
> Does it matter? The target CPU has NEED_RESCHED set, which should handle
> the pushing logic anyway, right?

I am not sure. The task can only be added with the rq and push-list with
rq-lock held then schedule() should see it by the time it picks the task
with the highest priority. But part of what needs to be done as of
rto_push_irq_work_func()/ push_rt_task() is to push tasks with lower
priority to another CPU. This isn't the case as far as I understand the
code.
This looks expensive to be performed in schedule() but then it is also
done via the IPI. On the plus side, after the RT has been made curr it
is removed from the list. So this could be already used as a hint if
this needs to be done or not. 

> Hmm, I probably should look deeper to make sure that anytime a schedule
> happens where there's overloaded RT tasks, it tries to push.

I think it tried pull on schedule but then it got outsourced to push via
the IPI with this new code. Don't remember the details 

> -- Steve

Sebastian