linux-kernel - Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

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: <20170523202956.7a2q4ysbqbnaik3n@hirez.programming.kicks-ass.net>
Date:   Tue, 23 May 2017 22:29:56 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Juri Lelli <juri.lelli@....com>
Cc:     mingo@...hat.com, rjw@...ysocki.net, viresh.kumar@...aro.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        tglx@...utronix.de, vincent.guittot@...aro.org,
        rostedt@...dmis.org, luca.abeni@...tannapisa.it,
        claudio@...dence.eu.com, tommaso.cucinotta@...tannapisa.it,
        bristot@...hat.com, mathieu.poirier@...aro.org, tkjos@...roid.com,
        joelaf@...gle.com, andresoportus@...gle.com,
        morten.rasmussen@....com, dietmar.eggemann@....com,
        patrick.bellasi@....com
Subject: Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP
 selection

On Tue, May 23, 2017 at 10:23:21PM +0200, Peter Zijlstra wrote:
> On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote:
> 
> > A point that is still very much up for discussion (more that the others :) is
> > how we implement frequency/cpu scaling. SCHED_FLAG_RECLAIM tasks only need
> > grub_reclaim(), as the function already scales their reservation runtime
> > considering other reservations and maximum bandwidth a CPU has to offer.
> > However, for normal !RECLAIM tasks multiple things can be implemented which
> > seem to make sense:
> > 
> >  - don't scale at all: normal tasks will only get a % of CPU _time_ as granted
> >    by AC
> >  - go to max as soon as a normal task in enqueued: this because dimensioning of
> >    parameters is usually done at max OPP/biggest CPU and normal task assume
> >    that this is always the condition when they run
> >  - scale runtime acconding to current frequency and max CPU capacity: this is
> >    what this set is currently implementing
> > 
> > Opinions?
> 
> 
> So I'm terribly confused...
> 
> By using the active bandwidth to select frequency we effectively
> reduce idle time (to 0 if we had infinite granular frequency steps and
> no margins).

When all DL tasks consume their full reservation.

> So !RECLAIM works as expected. They get the time they reserved, since
> that was taken into account by active bandwidth.
> 
> And RECLAIM works, since that only promises to (re)distribute idle time,
> and if there is none that is an easy task.

And if they don't, there will thus be some idle time to redistribute and
that, again, still works as expected.