linux-kernel - Re: [RESEND][RFC] sched: Introduce removed.load

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] [day] [month] [year] [list]

Message-ID: <CADHxFxTUvx4VvOizfhg7jeyenN7m+YX9Oro+ndPQ1sr_Y3d1Ag@mail.gmail.com>
Date: Wed, 15 Oct 2025 15:20:25 +0800
From: hupu <hupu.gm@...il.com>
To: Pierre Gondois <pierre.gondois@....com>, vincent.guittot@...aro.org
Cc: peterz@...radead.org, juri.lelli@...hat.com, mingo@...hat.com, 
	rostedt@...dmis.org, dietmar.eggemann@....com, vschneid@...hat.com, 
	bsegall@...gle.com, linux-kernel@...r.kernel.org, mgorman@...e.de
Subject: Re: [RESEND][RFC] sched: Introduce removed.load_sum for precise load propagation

Hi Vincent Guittot, Pierre Gondois, and fellow maintainers,

This PATCH has been pending for several days without any feedback.
Please allow me to RESEND this as a gentle reminder.

Thanks,
hupu


On Sat, Oct 11, 2025 at 10:27 AM hupu <hupu.gm@...il.com> wrote:
>
> Hi Pierre Gondois,
> Just wanted to mention a small detail that’s easy to miss.
>
> On Fri, Oct 10, 2025 at 7:37 PM hupu <hupu.gm@...il.com> wrote:
> > > It is possible to compute load_sum value without the runnable_signal, cf.
> > > 40f5aa4c5eae ("sched/pelt: Fix attach_entity_load_avg() corner case")
> > > https://lore.kernel.org/all/20220414090229.342-1-kuyo.chang@mediatek.com/T/#u
> > >
> > > I.e.:
> > > +       se->avg.load_sum = se->avg.load_avg * divider;
> > > +       if (se_weight(se) < se->avg.load_sum)
> > > +               se->avg.load_sum = div_u64(se->avg.load_sum, se_weight(se));
> > > +       else
> > > +               se->avg.load_sum = 1;
> > >
> > > As a side note, as a counterpart of the above patch, the lower the niceness,
> > > the lower the weight (in sched_prio_to_weight[]) and the lower the task
> > > load signal.
> > > This means that the unweighted load_sum value looses granularity.
> > > E.g.:
> > > A task with weight=15 can have load_avg values in [0:15]. So all the values
> > > for load_sum in the range [X * (47742/15) : (X + 1) * (47742/15)]
> > > are floored to load_avg=X, but load_sum is not reset when computing
> > > load_avg.
> > > attach_entity_load_avg() however resets load_sum to X * (47742/15).
> > >
> >
> > From a mathematical perspective, deriving load_sum from load_avg is
> > indeed feasible.
> >
> > However, as you pointed out, integer arithmetic may introduce
> > significant quantization errors, particularly for tasks with low
> > weights.
> >
> > For instance, if a task’s weight is 15 and its load_sum values are
> > 3183 and 6364 respectively, both would result in the same load_avg = 1
> > under this method — resulting in an error of 6364 - 3183 = 3181. This
> > error increases as the task’s weight decreases.
> >
> > Therefore, I believe that recomputing the propagated load_sum from
> > load_avg within update_cfs_rq_load_avg() is not an ideal approach.
> > Instead, my proposal is to record the load_sum of dequeued tasks
> > directly in cfs_rq->removed, rather than inferring it indirectly from
> > other signals such as runnable_sum or load_avg.
> >
>
> In addition, weight is a historical variable that may change over time
> due to dynamic priority adjustments. Therefore, reconstructing
> load_sum from load_avg using the current se_weight(se) in
> update_cfs_rq_load_avg() may be wrong, as it mixes values computed
> under different weight conditions.
>
> So, I believe directly recording each entity’s load_sum at dequeue
> time offers a more accurate and consistent approach.
>
> Thanks,
> hupu