Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1691475

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

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement scale-invariant
Date 2017-07-19 13:10 +0200
Message-ID <u4V1D-7Jj-9@gated-at.bofh.it> (permalink)
References <tZOtQ-4hV-5@gated-at.bofh.it> <tZOtQ-4hV-3@gated-at.bofh.it> <u4RAK-5hK-17@gated-at.bofh.it> <u4TsS-6zb-29@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jul 19, 2017 at 10:20:29AM +0100, Juri Lelli wrote:
> 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.

I don't think that quite works out. Given that the frequency selection
will never quite end up at exactly the same fraction (if the hardware
listens to your requests at all).

Also, by not scaling the GRUB stuff, don't you run the risk of
attempting to hand out more idle time than there actually is?

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Peter Zijlstra <peterz@infradead.org> - 2017-07-19 09:30 +0200
  Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Juri Lelli <juri.lelli@arm.com> - 2017-07-19 11:30 +0200
    Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Peter Zijlstra <peterz@infradead.org> - 2017-07-19 13:10 +0200
      Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Juri Lelli <juri.lelli@arm.com> - 2017-07-19 13:20 +0200
        Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Peter Zijlstra <peterz@infradead.org> - 2017-07-24 18:50 +0200
          Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Luca Abeni <luca.abeni@santannapisa.it> - 2017-07-25 09:10 +0200
            Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant Peter Zijlstra <peterz@infradead.org> - 2017-07-25 16:00 +0200
              Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement  scale-invariant luca abeni <luca.abeni@santannapisa.it> - 2017-07-26 16:00 +0200

csiph-web