linux-kernel - Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement scale-invariant

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: <20170719092029.oakmetq3u52e4rfw@e106622-lin>
Date:   Wed, 19 Jul 2017 10:20:29 +0100
From:   Juri Lelli <juri.lelli@....com>
To:     Peter Zijlstra <peterz@...radead.org>
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, Ingo Molnar <mingo@...nel.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement
 scale-invariant

On 19/07/17 09:21, Peter Zijlstra wrote:
> On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote:
> > @@ -1156,9 +1157,26 @@ static void update_curr_dl(struct rq *rq)
> >  	if (unlikely(dl_entity_is_special(dl_se)))
> >  		return;
> >  
> > -	if (unlikely(dl_se->flags & SCHED_FLAG_RECLAIM))
> > -		delta_exec = grub_reclaim(delta_exec, rq, &curr->dl);
> > -	dl_se->runtime -= delta_exec;
> > +	/*
> > +	 * For tasks that participate in GRUB, we implement GRUB-PA: the
> > +	 * spare reclaimed bandwidth is used to clock down frequency.
> > +	 *
> > +	 * For the others, we still need to scale reservation parameters
> > +	 * according to current frequency and CPU maximum capacity.
> > +	 */
> > +	if (unlikely(dl_se->flags & SCHED_FLAG_RECLAIM)) {
> > +		scaled_delta_exec = grub_reclaim(delta_exec,
> > +						 rq,
> > +						 &curr->dl);
> > +	} else {
> > +		unsigned long scale_freq = arch_scale_freq_capacity(cpu);
> > +		unsigned long scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
> > +
> > +		scaled_delta_exec = cap_scale(delta_exec, scale_freq);
> > +		scaled_delta_exec = cap_scale(scaled_delta_exec, scale_cpu);
> > +	}
> > +
> > +	dl_se->runtime -= scaled_delta_exec;
> >  
> 
> This I don't get... 


Considering that we use GRUB's active utilization to drive clock
frequency selection, rationale is that GRUB tasks don't need any special
scaling, as their delta_exec is already scaled according to GRUB rules.
OTOH, normal tasks need to have their runtime (delta_exec) explicitly
scaled considering current frequency (and CPU max capacity), otherwise
they are going to receive less runtime than granted at AC, when
frequency is reduced.