linux-kernel - Re: [RFC PATCH] sched/feec: Simplify the traversal of pd'cpus

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: <CAB8ipk9BDzsTTcdRKc9R_Hc72cOY8YyUfrCoY3_9hPJ8D-Fg_Q@mail.gmail.com>
Date: Thu, 14 Aug 2025 17:52:05 +0800
From: Xuewen Yan <xuewen.yan94@...il.com>
To: Dietmar Eggemann <dietmar.eggemann@....com>, Christian Loehle <christian.loehle@....com>
Cc: Xuewen Yan <xuewen.yan@...soc.com>, mingo@...hat.com, peterz@...radead.org, 
	juri.lelli@...hat.com, vincent.guittot@...aro.org, rostedt@...dmis.org, 
	bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com, 
	vdonnefort@...gle.com, ke.wang@...soc.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] sched/feec: Simplify the traversal of pd'cpus

Hi Dietmar,

On Thu, Aug 14, 2025 at 4:46 PM Dietmar Eggemann
<dietmar.eggemann@....com> wrote:
>
>
>
> On 12.08.25 10:33, Xuewen Yan wrote:
> > Now we use for_each_cpu() to traversal all pd's cpus,
> > it is in order to compute the pd_cap. This approach may
> > result in some unnecessary judgments.
> > We can simply calculate pd_cap as follows:
> >
> > pd_cap = cpu_actual_cap * cpumask_weight(pd_cpus);
> >
> > Then we can AND pd'scpus, sd's cpus and task's cpus_ptr
> > before traversing, which can save some unnecessary judgment.
> >
> > Signed-off-by: Xuewen Yan <xuewen.yan@...soc.com>
> > ---
> >  kernel/sched/fair.c | 14 ++++----------
> >  1 file changed, 4 insertions(+), 10 deletions(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index b173a059315c..e47fe94d6889 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -8330,18 +8330,12 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
>
> Just a thought ...
>
> for (; pd; pd = pd->next)
>
>   cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);    <-- (1)
>   cpumask_and(cpus, perf_domain_span(pd), cpu_online_mask);
>
>
>   if (cpumask_empty(cpus))
>     continue;                                               <-- (2)
>
> Can you not mask cpus already early in the pd loop (1) and then profit
> from (2) in these rare cases?

I do not think the cpus_ptr chould place before the pd_cap calc,
because the following scenario should be considered:
the task's cpus_ptr cpus： 0,1,2,3
pd's cpus: 0,1,2,3,4,5,6
the pd's cap = cpu_cap * 6;
if we cpumask_and(pd'scpus, p->cpus_ptr),
the cpumask_weight = 4,
the pd's cap = cpu_cap *4.


> IIRC, the sd only plays a role here in
> exclusive cpusets scenarios which I don't thing anybody deploys with EAS?

I am also wondering if the check for SD's CPUs could be removed...

Thanks!
>
> >               cpu_actual_cap = get_actual_cpu_capacity(cpu);
> >
> >               eenv.cpu_cap = cpu_actual_cap;
> > -             eenv.pd_cap = 0;
> > +             eenv.pd_cap = cpu_actual_cap * cpumask_weight(cpus);
> >
> > -             for_each_cpu(cpu, cpus) {
> > -                     struct rq *rq = cpu_rq(cpu);
> > -
> > -                     eenv.pd_cap += cpu_actual_cap;
> > -
> > -                     if (!cpumask_test_cpu(cpu, sched_domain_span(sd)))
> > -                             continue;
> > +             cpumask_and(cpus, cpus, sched_domain_span(sd));
> >
> > -                     if (!cpumask_test_cpu(cpu, p->cpus_ptr))
> > -                             continue;
> > +             for_each_cpu_and(cpu, cpus, p->cpus_ptr) {
> > +                     struct rq *rq = cpu_rq(cpu);
> >
> >                       util = cpu_util(cpu, p, cpu, 0);
> >                       cpu_cap = capacity_of(cpu);
>