Re: [BUG] Apparent lost wakeups

[K Prateek Nayak]

Hello Joel,

On 10/13/2026 6:19 PM, Joel Fernandes wrote:
> Quick question - with that fix, is there a possibility of a live lock if the sched loop keeps restarting because another CPU kept toggling RT?

__schedule() only drops rq_lock for two activities:

1. Within sched class' balance callback: This is done from all classes
   from donor's sched class to below. Once a task is found by the
   balance callback, we break out of prev_balance() and jump straight
   to pick so something is guaranteed to be there.

   All balance callbacks use double_rq_lock() so we are guaranteed to
   move the task from a source rq.

2. For newidle balance: When no tasks exists on rq, fair class will do
   a newidle balance to try find a task and prevent the need to switch
   to idle tasks.

   If a fair task is found or woken up, the retry is limited to idle
   class. If a higher priority task is woken up, we do a full re-pick
   starting from top.


Now, in theory, there is a possibility where:

1. rq->donor is a high priority RT task that went to sleep.

2. Lower priority RT tasks (>= 2) wakeup on the same CPU during
   newidle balance. A retry is triggered.

3. balance_rt() triggers a pull because the newly woken tasks have a
   lower priority than rq->donor which went to sleep.

4. pull_rt_task() drops rq_lock during double_rq_lock_balance()

5. A different rq gets lock first and moves the RT tasks away.

6. double_rq_lock_balance() returns, finds no task to push, and
   eventually __schedule() goes to pick.

7. Fair class' pick triggers newidle balance and jump to step 2.


I'm not sure if there is a safeguard for this case where the CPU
can get stuck looping in pick_next_task() but chances of triggering
it is small (albeit not zero). This can happen even without the
changes from this patch.

Maybe I'm missing something and Peter can enlighten why this is
all impossible :-)

-- 
Thanks and Regards,
Prateek