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