linux-kernel - Re: [PATCH] sched/fair: use signed long when compute energy delta in eas

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: <CAB8ipk9JATYxJBnpVFfH_XHLqh=yHesbo73wx=Mm7t8mSqW_Gg@mail.gmail.com>
Date:   Tue, 6 Apr 2021 18:59:16 +0800
From:   Xuewen Yan <xuewen.yan94@...il.com>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Quentin Perret <qperret@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Benjamin Segall <bsegall@...gle.com>,
        Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        quentin.perret@....com, Chunyan Zhang <zhang.lyra@...il.com>,
        Ryan Y <xuewyan@...mail.com>,
        Pierre Gondois <pierre.gondois@....com>
Subject: Re: [PATCH] sched/fair: use signed long when compute energy delta in eas

Hi Dietmar

On Fri, Apr 2, 2021 at 2:07 AM Dietmar Eggemann
<dietmar.eggemann@....com> wrote:
>
> +cc: Pierre Gondois <pierre.gondois@....com>
>
> On 30/03/2021 11:45, Quentin Perret wrote:
> > Hi,
> >
> > On Tuesday 30 Mar 2021 at 13:21:54 (+0800), Xuewen Yan wrote:
> >> From: Xuewen Yan <xuewen.yan@...soc.com>
> >>
> >> now the energy delta compute as follow:
> >>
> >> base_energy_pd = compute_energy(p, -1, pd);
> >>      --->Traverse all CPUs in pd
> >>      --->em_pd_energy()
> >> ----------------------------------------------------- \
> >> search for the max_sapre_cap_cpu                       \
> >> ---------------------------------                       search time
> >> cur_delta = compute_energy(p, max_spare_cap_cpu, pd);  /
> >>      --->Traverse all CPUs in pd                   /
> >> ---------------------------------------------------- /
> >>      --->em_pd_energy()
> >> cur_delta -= base_energy_pd;
> >>
> >> During the search_time, or when calculate the cpu_util in
> >> compute_energy(), there may occurred task dequeue or cpu_util change,
> >> it may cause the cur_energy < base_energy_pd, so the cur_delta
> >> would be negative. But the cur_delta is unsigned long, at this time,
> >> the cur_delta would always bigger than best_delta of last pd.
> >>
> >> Change the vars to signed long.
> >
> > Is that really helping though?
> >
> > Yes you will not overflow, but the decision is still 'wrong' if the util
> > values are not stable for the entire wake-up. I think folks on the Arm
> > side had patches to try and cache the util values upfront, and then use
> > them throughout feec() and compute_energy(), which I think would be a
> > better fix.
> >
> > Dietmar, wdyt?
>
> Yes, we have some patches from Pierre Gondois which introduce a pd cache
> to store the CPU utilization values so they can be reused for 'cpu !=
> dst_cpu' calculations within find_energy_efficient_cpu() (feec()).
>
> We did run them in our Jan 2021 EAS integration:
>
> https://gitlab.arm.com/linux-arm/linux-power/-/commits/eas/next/integration-20210129
>
>   sched: Allocate pd_cache when EAS is enabled
>   sched/fair: Use pd_cache to speed up find_energy_efficient_cpu()
>
> We haven't posted them since we're still looking for a story to justify
> the extra complexity. The experiments on Arm64 Juno (2 big, 4 little
> CPUs) showed 1-2% failure due to changes of CPU utilization values
> during feec(). There was a 5% (big CPU)-10% (little CPU) runtime
> reduction for feec() with the patches.

I test the patch, but the overflow still exists.
In the "sched/fair: Use pd_cache to speed up find_energy_efficient_cpu()"
I wonder why recompute the cpu util when cpu==dst_cpu in compute_energy(),
when the dst_cpu's util change, it also would cause the overflow.

Thanks