Re: [PATCH] sched/eevdf: Update se->vprot in reweight_entity()

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

Hello Peter,

On 1/23/2026 9:08 PM, Peter Zijlstra wrote:
> On Wed, Jan 21, 2026 at 06:00:15PM +0100, Vincent Guittot wrote:
> 
>> Why not use update_protect_slice() like when a new task with a shorter
>> slice is added ?
> 
> That seems wrong too...
> 
> I was going over this, and should we not limit set_protect_slice() to
> the first set_next_entity(). That is, AFAICT we'll re-set it on
> sched_change -- which sounds wrong to me.

That makes sense.

> 
> Anyway, I ended up with something like so (should probably be split in
> two patches).
> 
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index eca642295c4b..bab51da3d179 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3790,6 +3790,7 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  			    unsigned long weight)
>  {
>  	bool curr = cfs_rq->curr == se;
> +	u64 vprot = 0;
>  
>  	if (se->on_rq) {
>  		/* commit outstanding execution time */
> @@ -3797,6 +3798,9 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  		update_entity_lag(cfs_rq, se);
>  		se->deadline -= se->vruntime;
>  		se->rel_deadline = 1;
> +		if (curr && protect_slice(se))
> +			vprot = se->vprot - se->vruntime;
> +
>  		cfs_rq->nr_queued--;
>  		if (!curr)
>  			__dequeue_entity(cfs_rq, se);
> @@ -3812,6 +3816,9 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  	if (se->rel_deadline)
>  		se->deadline = div_s64(se->deadline * se->load.weight, weight);
>  
> +	if (vprot)
> +		vprot = div_s64(vprot * se->load.weight, weight);
> +
>  	update_load_set(&se->load, weight);
>  
>  	do {
> @@ -3823,6 +3830,8 @@ static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  	enqueue_load_avg(cfs_rq, se);
>  	if (se->on_rq) {
>  		place_entity(cfs_rq, se, 0);
> +		if (vprot)
> +			se->vprot = se->vruntime + vprot;

Scaling vprot makes sense too. Can there be a problem where "vprot"
turns to zero on scaling (weight > (vprot * se->load.weight)) but we
don't end up updating "se->vprot"?

Probably rare but a higher weight implies it might take a tad bit
longer to hit that old "vprot" but since we are losing the precision,
can the pending "se->vprot" be big enough to cause any issue?

Since we are looking at these bits, can you also please take a look at
https://lore.kernel.org/lkml/20251226001731.3730586-1-quzicheng@huawei.com/
which I feel might be a genuine issue when we are reweight the curr's
vruntime.

>  		update_load_add(&cfs_rq->load, se->load.weight);
>  		if (!curr)
>  			__enqueue_entity(cfs_rq, se);

-- 
Thanks and Regards,
Prateek