linux-kernel - Re: [PATCH 0/4] sched: Various reweight

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfTPtBQf_3ByhMq6G5b12L+w=kOyMTg11feKhNWinyKJAaarg@mail.gmail.com>
Date: Wed, 11 Feb 2026 12:15:48 +0100
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Doug Smythies <dsmythies@...us.net>, K Prateek Nayak <kprateek.nayak@....com>, mingo@...nel.org, 
	juri.lelli@...hat.com, dietmar.eggemann@....com, rostedt@...dmis.org, 
	bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com, 
	linux-kernel@...r.kernel.org, wangtao554@...wei.com, quzicheng@...wei.com, 
	wuyun.abel@...edance.com
Subject: Re: [PATCH 0/4] sched: Various reweight_entity() fixes

On Wed, 11 Feb 2026 at 11:48, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Wed, Feb 11, 2026 at 10:01:44AM +0100, Peter Zijlstra wrote:
>
> > > There 2 issues with patch 3
> > >
> > > *one scale_load_down remains in avg_vruntime
> > >
> > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > index 25c398ff0d59..3143ae7f07b0 100644
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -778,7 +778,7 @@ u64 avg_vruntime(struct cfs_rq *cfs_rq)
> > >
> > >         if (weight) {
> > >                 if (curr) {
> > > -                       unsigned long w = scale_load_down(curr->load.weight);
> > > +                       unsigned long w =
> > > avg_vruntime_weight(curr->load.weight);
> > >
> > >                         runtime += entity_key(cfs_rq, curr) * w;
> > >                         weight += w;
> >
> > AAARGHHH!! Sorry about that, clearly I've not been careful with
> > reshuffling patches :-(
>
> So with that one fixed; I get (as queue/sched/core of just now):

yes, this is the root cause of the regression

Regarding the use of calc_delta_fair() in update_entity_lag(), we use
calc_delta_fair() for updating vruntime, deadline, vprot and vlag and
I wonder how this diff of granularity compared to avg_vruntime can be
an issue for sched_entity with a  small weight


>
> base:
>
> 1:            0.25431 +- 0.00226 seconds time elapsed  ( +-  0.89% )
> 2:            0.52522 +- 0.00304 seconds time elapsed  ( +-  0.58% )
> 5:            1.10452 +- 0.00509 seconds time elapsed  ( +-  0.46% )
> 10:           2.00673 +- 0.00761 seconds time elapsed  ( +-  0.38% )
> 20:           3.81795 +- 0.00347 seconds time elapsed  ( +-  0.09% )
> 40:           7.0551  +- 0.0112  seconds time elapsed  ( +-  0.16% )
>
> +1      patches/peterz-sched-fair-fix-zero_vruntime.patch
>
> 1:            0.25231 +- 0.00328 seconds time elapsed  ( +-  1.30% )
> 2:            0.52794 +- 0.00337 seconds time elapsed  ( +-  0.64% )
> 5:            1.09336 +- 0.00391 seconds time elapsed  ( +-  0.36% )
> 10:           1.98787 +- 0.00660 seconds time elapsed  ( +-  0.33% )
> 20:           3.75865 +- 0.00782 seconds time elapsed  ( +-  0.21% )
> 40:           7.0208  +- 0.0102  seconds time elapsed  ( +-  0.15% )
>
> +2      patches/peterz-sched-fair-curb-set_protect_slice.patch
>
> 1:            0.25421 +- 0.00351 seconds time elapsed  ( +-  1.38% )
> 2:            0.53178 +- 0.00308 seconds time elapsed  ( +-  0.58% )
> 5:            1.09421 +- 0.00462 seconds time elapsed  ( +-  0.42% )
> 10:           1.99843 +- 0.00289 seconds time elapsed  ( +-  0.14% )
> 20:           3.77249 +- 0.00676 seconds time elapsed  ( +-  0.18% )
> 40:           7.0371  +- 0.0143  seconds time elapsed  ( +-  0.20% )
>
> +3      patches/wang_tao-sched_eevdf-update_se-_vprot_in_reweight_entity.patch
>
> 1:            0.25141 +- 0.00342 seconds time elapsed  ( +-  1.36% )
> 2:            0.53294 +- 0.00474 seconds time elapsed  ( +-  0.89% )
> 5:            1.10944 +- 0.00447 seconds time elapsed  ( +-  0.40% )
> 10:           2.00012 +- 0.00366 seconds time elapsed  ( +-  0.18% )
> 20:           3.77650 +- 0.00796 seconds time elapsed  ( +-  0.21% )
> 40:           7.0455  +- 0.0145  seconds time elapsed  ( +-  0.21% )
>
> +4      patches/peter_zijlstra-sched_fair-increase_max_lag_clamping.patch
>
> 1:            0.25096 +- 0.00415 seconds time elapsed  ( +-  1.65% )
> 2:            0.53635 +- 0.00372 seconds time elapsed  ( +-  0.69% )
> 5:            1.12040 +- 0.00549 seconds time elapsed  ( +-  0.49% )
> 10:           2.00447 +- 0.00518 seconds time elapsed  ( +-  0.26% )
> 20:           3.7682  +- 0.0104  seconds time elapsed  ( +-  0.28% )
> 40:           7.0023  +- 0.0141  seconds time elapsed  ( +-  0.20% )
>
> +5      patches/peterz-sched-increase-avg-bits.patch
>
> 1:            0.24866 +- 0.00284 seconds time elapsed  ( +-  1.14% )
> 2:            0.52756 +- 0.00310 seconds time elapsed  ( +-  0.59% )
> 5:            1.09946 +- 0.00643 seconds time elapsed  ( +-  0.58% )
> 10:           1.98256 +- 0.00398 seconds time elapsed  ( +-  0.20% )
> 20:           3.75988 +- 0.00611 seconds time elapsed  ( +-  0.16% )
> 40:           6.9833  +- 0.0113  seconds time elapsed  ( +-  0.16% )
>
> +6      patches/peterz-sched-revert-reweight-entity-thingy.patch
>
> 1:            0.25302 +- 0.00285 seconds time elapsed  ( +-  1.13% )
> 2:            0.53040 +- 0.00383 seconds time elapsed  ( +-  0.72% )
> 5:            1.08806 +- 0.00341 seconds time elapsed  ( +-  0.31% )
> 10:           1.97696 +- 0.00592 seconds time elapsed  ( +-  0.30% )
> 20:           3.75393 +- 0.00622 seconds time elapsed  ( +-  0.17% )
> 40:           6.9794  +- 0.0139  seconds time elapsed  ( +-  0.20% )
>
>
> Now let me go check on that latency thing from Doug (although hopefully
> that was the same boo-boo).