linux-kernel - Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup

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: <20190508144716.5cc8445d@nowhere>
Date:   Wed, 8 May 2019 14:47:16 +0200
From:   luca abeni <luca.abeni@...tannapisa.it>
To:     Juri Lelli <juri.lelli@...hat.com>
Cc:     linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        "Paul E . McKenney" <paulmck@...ux.ibm.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Quentin Perret <quentin.perret@....com>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Tommaso Cucinotta <tommaso.cucinotta@...tannapisa.it>
Subject: Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup

Hi Juri,

On Wed, 8 May 2019 14:05:26 +0200
Juri Lelli <juri.lelli@...hat.com> wrote:
[...]
> > > > +	if ((rel_deadline < 0) || (rel_deadline *
> > > > dl_se->dl_runtime < dl_se->dl_deadline * rem_runtime)) {
> > > > +		rel_deadline = dl_se->dl_deadline;
> > > > +		rem_runtime  = dl_se->dl_runtime;
> > > > +	}    
> > > 
> > > So, are you basically checking if current remaining bw can be
> > > consumed safely?  
> > 
> > I check if the current runtime (rescaled based on the capacity) is
> > smaller than the time to the current scheduling deadline
> > (basically, if it can be consumed in time).
> > 
> > However, if
> > 	q / (d - t) > Q / P 
> > (where "q" is the current runtime, "d" is the scheduling deadline,
> > "Q" is the maximum runtime, and "P" is the CBS period), then a new
> > scheduling deadline will be generated (later), and the runtime will
> > be reset to Q... So, I need to use the maximum budget and CBS
> > period for checking if the task fits in the core.  
> 
> OK. I'd add a comment about it.

Ok; I'll add a comment in the next version of the patchset.


[...]
> > > I'm not actually sure if looking at dynamic values is what we
> > > need to do at this stage. By considering static values we fix
> > > admission control (and scheduling). Aren't dynamic values more to
> > > do with energy tradeoffs (and so to be introduced when starting
> > > to look at the energy model)?  
> > 
> > Using the current runtime and scheduling deadline might allow to
> > migrate a task to SMALL cores (if its remaining runtime is small
> > enough), even if the rescaled Q is larger than P.
> > So, in theory it might allow to reduce the load on big cores.
> > 
> > If we decide that this is overkilling, I can just drop the patch.  
> 
> So, my first impression was that we shouldn't be too clever until we
> start using info from the energy model (using which one should be able
> to understand if, for example, reducing load on big cores is a winning
> power/perf decision).

Ok.


> However, I was also wondering if we should actually compare dynamic
> parameters with {running,this}_bw (per-rq) the moment we search for
> potential migration candidates (so that we are not overloading rqs).

Notice that all this logic is used only to select one of the idle cores
(instead of picking the first idle core, we select the less powerful
core on which the task "fits").

So, running_bw does not provide any useful information, in this case;
maybe this_bw can be more useful.



				Luca