Re: [PATCH v2 10/10] sched/eevdf: Move to a single runqueue

From: K Prateek Nayak

Date: Tue May 26 2026 - 07:00:01 EST


Hello Peter,

On 5/26/2026 3:22 PM, Peter Zijlstra wrote:
> On Tue, May 26, 2026 at 02:45:45PM +0530, K Prateek Nayak wrote:
>
>> The suggested diff above solves the crash in my case but your
>> mileage may vary. Peter can comment if this is the right thing
>> to do or not :-)
>
> Is this a different issue than the one you raised before?

Yes, this is different. Essentially, this is what is happening:

throttle_cfs_rq_work()
task_rq_lock()

dequeue_task_fair(current) /* Task is dequeued on cfs side */
__dequeue_task(current)
dequeue_hierarchy(current);
current->se.on_rq = 0;
/* update_load_sub() */
resched_curr(); /* Initiates a resched */

task_rq_unlock()
local_irq_enable();

=====> sched_tick()
task_tick_fair()
__calc_prop_weight()
/*
* Oops: update_load_sub() above has
* 0ed the weight of cfs_rq.
*/
<====

preempt_schedule_irq()
next = ...
put_prev_set_next_task() /* The runtime context is switched here */


> We talked about throtte, and you were going to make a proper patch of that cleanup
> iirc.

I had rebased your suggestion on tip and fixed a couple of splats but
once it was functional, I noticed hackbench taking twice as long to
complete compared to tip and I was chasing that before I fell sick.

Let me go dig deeper to see where exactly it is all going sideways.

--
Thanks and Regards,
Prateek