Re: [PATCH 4/6 v8] sched/fair: Add push task mechanism for fair

[K Prateek Nayak <kprateek.nayak@amd.com>]

On 12/5/2025 2:29 PM, Peter Zijlstra wrote:
>>> Why not use move_queued_task() ?
>>
>> double_lock_balance() can fail and prevent being blocked waiting for
>> new rq whereas move_queued_task() will wait, won't it ?
>>
>> Do you think move_queued_task() would be better ?
> 
> No, double_lock_balance() never fails, the return value indicates if the
> currently held rq-lock, (the first argument) was unlocked while
> attaining both -- this is required when the first rq is a higher address
> than the second.
> 
> double_lock_balance() also puts the wait-time and hold time of the
> second inside the hold time of the first, which gets you a quadric term
> in the rq hold times IIRC. Something that's best avoided.
> 
> move_queued_task() OTOH takes the task off the runqueue you already hold
> locked, drops this lock, acquires the second, puts the task there, and
> returns with the dst rq locked.

So I was experimenting with:

    deactivate_task(rq, p, 0);
    set_task_cpu(p, target_cpu);
    __ttwu_queue_wakelist(p, target_cpu, 0);

and nothing has screamed at me yet during the benchmark runs.
Would this be any good instead of the whole lock juggling?

Since this CPU is found to be going overloaded, pushing via an
IPI vs taking the overhead ourselves seems to make more sense
to me from EAS standpoint.

Given TTWU_QUEUE is disabled for PREEMPT_RT, I'm assuming this
might be problematic too?

-- 
Thanks and Regards,
Prateek