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]

Date:   Wed, 8 May 2019 14:05:26 +0200
From:   Juri Lelli <juri.lelli@...hat.com>
To:     luca abeni <luca.abeni@...tannapisa.it>
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

On 08/05/19 11:24, luca abeni wrote:
> On Wed, 8 May 2019 11:08:55 +0200
> Juri Lelli <juri.lelli@...hat.com> wrote:
> 
> > On 06/05/19 06:48, Luca Abeni wrote:
> > > From: luca abeni <luca.abeni@...tannapisa.it>
> > > 
> > > Instead of considering the "static CPU bandwidth" allocated to
> > > a SCHED_DEADLINE task (ratio between its maximum runtime and
> > > reservation period), try to use the remaining runtime and time
> > > to scheduling deadline.
> > > 
> > > Signed-off-by: luca abeni <luca.abeni@...tannapisa.it>
> > > ---
> > >  kernel/sched/cpudeadline.c | 9 +++++++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
> > > index d21f7905b9c1..111dd9ac837b 100644
> > > --- a/kernel/sched/cpudeadline.c
> > > +++ b/kernel/sched/cpudeadline.c
> > > @@ -114,8 +114,13 @@ static inline int dl_task_fit(const struct
> > > sched_dl_entity *dl_se, int cpu, u64 *c)
> > >  {
> > >  	u64 cap = (arch_scale_cpu_capacity(NULL, cpu) *
> > > arch_scale_freq_capacity(cpu)) >> SCHED_CAPACITY_SHIFT;
> > > -	s64 rel_deadline = dl_se->dl_deadline;
> > > -	u64 rem_runtime  = dl_se->dl_runtime;
> > > +	s64 rel_deadline = dl_se->deadline -
> > > sched_clock_cpu(smp_processor_id());
> > > +	u64 rem_runtime  = dl_se->runtime;
> > > +
> > > +	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.

> > 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).

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).