[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260123213140.GB3268448@noisy.programming.kicks-ass.net>
Date: Fri, 23 Jan 2026 22:31:40 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: Vincent Guittot <vincent.guittot@...aro.org>,
"wangtao (EQ)" <wangtao554@...wei.com>, mingo@...hat.com,
juri.lelli@...hat.com, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, tanghui20@...wei.com, zhangqiao22@...wei.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/eevdf: Update se->vprot in reweight_entity()
On Fri, Jan 23, 2026 at 10:09:05PM +0530, K Prateek Nayak wrote:
> > @@ -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"?
Yeah, this can happen, but in that case the thing is 'small'. I'll see
if I can fix it though.
> 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.
Oh, I hadn't found that yet -- people should know better than to send
mail during x-mas ;-)
Powered by blists - more mailing lists