linux-kernel - Re: [PATCH v6 08/11] cpufreq/schedutil: take into account interrupt

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: <20180612092028.GG17720@e108498-lin.cambridge.arm.com>
Date:   Tue, 12 Jun 2018 10:20:29 +0100
From:   Quentin Perret <quentin.perret@....com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     peterz@...radead.org, mingo@...nel.org,
        linux-kernel@...r.kernel.org, rjw@...ysocki.net,
        juri.lelli@...hat.com, dietmar.eggemann@....com,
        Morten.Rasmussen@....com, viresh.kumar@...aro.org,
        valentin.schneider@....com, patrick.bellasi@....com,
        joel@...lfernandes.org, daniel.lezcano@...aro.org,
        luca.abeni@...tannapisa.it, claudio@...dence.eu.com,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v6 08/11] cpufreq/schedutil: take into account interrupt

On Tuesday 12 Jun 2018 at 11:16:56 (+0200), Vincent Guittot wrote:
> The time spent under interrupt can be significant but it is not reflected
> in the utilization of CPU when deciding to choose an OPP. Now that we have
> access to this metric, schedutil can take it into account when selecting
> the OPP for a CPU.
> rqs utilization don't see the time spend under interrupt context and report
> their value in the normal context time window. We need to compensate this when
> adding interrupt utilization
> 
> The CPU utilization is :
>   irq util_avg + (1 - irq util_avg / max capacity ) * /Sum rq util_avg
> 
> A test with iperf on hikey (octo arm64) gives:
> iperf -c server_address -r -t 5
> 
> w/o patch		w/ patch
> Tx 276 Mbits/sec        304 Mbits/sec +10%
> Rx 299 Mbits/sec        328 Mbits/sec +09%
> 
> 8 iterations
> stdev is lower than 1%
> Only WFI idle state is enable (shallowest diel state)
                                            ^^^^
nit: s/diel/idle

And, out of curiosity, what happens if you leave the idle states
untouched ? Do you still see an improvement ? Or is it lost in the
noise ?

Thanks,
Quentin