[PATCH] sched/core: Fix stale se.load when modifying nice value under sched_ext

[PATCH] sched/core: Fix stale se.load when modifying nice value under sched_ext

[Wanwu Li]

From: Wanwu Li <liwanwu@kylinos.cn>

When a task's nice value is modified while running under sched_ext
scheduling class, set_load_weight() calls reweight_task() which only
updates static_prio but leaves p->se.load unchanged because sched_ext
does not use it. After switching back to CFS, the stale se.load leads
to incorrect load weight calculation.

Fix this by explicitly refreshing p->se.load for sched_ext tasks after
calling reweight_task().

Fixes: d32960528702 ("sched/fair: set_load_weight() must also call reweight_task() for SCHED_IDLE tasks")
Signed-off-by: Wanwu Li <liwanwu@kylinos.cn>
---
 kernel/sched/core.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 96226707c2f6..ebeadec41eb6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1538,10 +1538,21 @@ void set_load_weight(struct task_struct *p, bool update_load)
 	 * SCHED_OTHER tasks have to update their load when changing their
 	 * weight
 	 */
-	if (update_load && p->sched_class->reweight_task)
+	if (update_load && p->sched_class->reweight_task) {
 		p->sched_class->reweight_task(task_rq(p), p, &lw);
-	else
+
+		/*
+		 * If modify nice while task runs under ext class, only
+		 * static_prio updates, p->se.load stays stale and mismatches
+		 * the new nice value. After switching back to CFS, outdated
+		 * load leads to incorrect weight. Synchronously refresh
+		 * se.load to keep priority state consistent.
+		 */
+		if (task_on_scx(p))
+			p->se.load = lw;
+	} else {
 		p->se.load = lw;
+	}
 }
 
 #ifdef CONFIG_UCLAMP_TASK
-- 
2.25.1

Re: [PATCH] sched/core: Fix stale se.load when modifying nice value under sched_ext

[K Prateek Nayak]

Hello Wanwu,

On 7/14/2026 2:43 PM, Wanwu Li wrote:
> [You don't often get email from liwanwu9113@163.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> From: Wanwu Li <liwanwu@kylinos.cn>
> 
> When a task's nice value is modified while running under sched_ext
> scheduling class, set_load_weight() calls reweight_task() which only
> updates static_prio but leaves p->se.load unchanged because sched_ext
> does not use it. After switching back to CFS, the stale se.load leads
> to incorrect load weight calculation.
> 
> Fix this by explicitly refreshing p->se.load for sched_ext tasks after
> calling reweight_task().
> 
> Fixes: d32960528702 ("sched/fair: set_load_weight() must also call reweight_task() for SCHED_IDLE tasks")
> Signed-off-by: Wanwu Li <liwanwu@kylinos.cn>

Isn't this solved in
https://lore.kernel.org/lkml/20260528131238.3879110-1-quzicheng315@gmail.com/ 

-- 
Thanks and Regards,
Prateek

Re: [PATCH] sched/core: Fix stale se.load when modifying nice value under sched_ext

[liwanwu9113]

Hello Prateek,

Thank you for your reply and correction.

I was not aware that this problem had already been addressed by another 
patch. I appreciate you taking the time to share this information. 
Please consider my patch withdrawn.

Thank you again for your guidance.

Best regards,
Wanwu Li

On 2026/7/14 17:30, K Prateek Nayak wrote:
> Hello Wanwu,
> 
> On 7/14/2026 2:43 PM, Wanwu Li wrote:
>> [You don't often get email from liwanwu9113@163.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> From: Wanwu Li <liwanwu@kylinos.cn>
>>
>> When a task's nice value is modified while running under sched_ext
>> scheduling class, set_load_weight() calls reweight_task() which only
>> updates static_prio but leaves p->se.load unchanged because sched_ext
>> does not use it. After switching back to CFS, the stale se.load leads
>> to incorrect load weight calculation.
>>
>> Fix this by explicitly refreshing p->se.load for sched_ext tasks after
>> calling reweight_task().
>>
>> Fixes: d32960528702 ("sched/fair: set_load_weight() must also call reweight_task() for SCHED_IDLE tasks")
>> Signed-off-by: Wanwu Li <liwanwu@kylinos.cn>
> 
> Isn't this solved in
> https://lore.kernel.org/lkml/20260528131238.3879110-1-quzicheng315@gmail.com/
>