linux-kernel - Re: [PATCH v5 00/10] track CPU utilization

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]

Date:   Thu, 7 Jun 2018 09:25:22 +0100
From:   Quentin Perret <quentin.perret@....com>
To:     luca abeni <luca.abeni@...tannapisa.it>
Cc:     Claudio Scordino <claudio@...dence.eu.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <Morten.Rasmussen@....com>,
        viresh kumar <viresh.kumar@...aro.org>,
        Valentin Schneider <valentin.schneider@....com>
Subject: Re: [PATCH v5 00/10] track CPU utilization

Hi Luca,

On Wednesday 06 Jun 2018 at 23:05:36 (+0200), luca abeni wrote:
> Hi,
> 
> On Wed, 6 Jun 2018 14:20:46 +0100
> Quentin Perret <quentin.perret@....com> wrote:
> [...]
> > > However, IMHO, these are corner cases and in the average case it is
> > > better to rely on running_bw and reduce the CPU frequency
> > > accordingly.  
> > 
> > My point was that accepting to go at a lower frequency than required
> > by this_bw is fundamentally unsafe. If you're at a low frequency when
> > a DL task starts, there are real situations where you won't be able
> > to increase the frequency immediately, which can eventually lead to
> > missing deadlines. Now, if this risk is known, has been discussed,
> > and is accepted, that's fair enough. I'm just too late for the
> > discussion :-)
> 
> Well, our conclusion was that this issue can be addressed when
> designing the scheduling parameters:
> - If we do not consider frequency scaling, a task can respect its
>   deadlines if the SCHED_DEADLINE runtime is larger than the task's
>   execution time and the SCHED_DEADLINE period is smaller than the
>   task's period (and if some kind of "global" admission test is
>   respected)
> - Considering frequency scaling (and 0-time frequency switches), the
>   SCHED_DEADLINE runtime must be larger than the task execution time at
>   the highest frequency
> - If the frequency switch time is larger than 0, then the
>   SCHED_DEADLINE runtime must be larger than the task execution time
>   (at the highest frequency) plus the frequency switch time
> 
> If this third condition is respected, I think that deadline misses can
> be avoided even if running_bw is used (and the CPU takes a considerable
> time to switch frequency). Of course, this requires an over-allocation
> of runtime (and the global admission test has more probabilities to
> fail)...

Ah, right, this third condition should definitely be a valid workaround
to the issue I mentioned earlier. And the runtime parameter is already
very much target-dependent I guess, so it should be fine to add another
target-specific component (the frequency-switching time) to the runtime
estimation.

And, if you really need to have tight runtimes to fit all of your tasks,
then you should just use a fixed frequency I guess ... At least the
current implementation gives a choice to the user between being
energy-efficient using sugov with over-allocated runtimes and having
tighter runtimes with the performance/powersave/userspace governor, so
that's all good :-)

Thank you very much,
Quentin