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

Groups > linux.kernel > #1649384

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

Show key headers only | View raw

On Wed, May 24, 2017 at 10:25:05AM +0100, Juri Lelli wrote:
> Hi,
> 
> On 23/05/17 22:23, 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).
> > 
> > So !RECLAIM works as expected. They get the time they reserved, since
> > that was taken into account by active bandwidth.
> > 
> 
> This was my impression as well, but Luca (and please Luca correct me if
> I misunderstood your point) argued (in an off-line discussion ahead of
> this posting) that !reclaim tasks might not be interested in reclaiming
> *at all*. Since scaling frequency down is another way of effectively
> reclaiming unused bandwidth (the other being sharing unused bandwidth
> among reservations while keeping frequency at max), !reclaim tasks could
> not be interested in frequency scaling (my first point above) or require
> frequency to be always at max (second point above).
> 
> Does this help claryfing a bit? :)

No ;-) As you said, confusion++.

A !RECLAIM task doesn't care (cannot care, should not care etc..) about
any bandwidth not allocated to itself. Therefore it should/must/etc..
not have any opinion on what we do with 'spare' bandwidth.

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

Thread

[PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-05-23 11:00 +0200
  [PATCH RFC 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli <juri.lelli@arm.com> - 2017-05-23 11:00 +0200
  [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli <juri.lelli@arm.com> - 2017-05-23 11:00 +0200
    Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization  signals Peter Zijlstra <peterz@infradead.org> - 2017-05-23 21:10 +0200
      Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization  signals Juri Lelli <juri.lelli@arm.com> - 2017-05-24 11:10 +0200
    Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization  signals Peter Zijlstra <peterz@infradead.org> - 2017-05-23 21:40 +0200
      Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-05-24 01:40 +0200
        Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization  signals Peter Zijlstra <peterz@infradead.org> - 2017-05-24 09:10 +0200
          Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization  signals Juri Lelli <juri.lelli@arm.com> - 2017-05-24 11:10 +0200
  Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-05-23 22:40 +0200
  Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 00:00 +0200
    Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Juri Lelli <juri.lelli@arm.com> - 2017-05-24 11:30 +0200
      Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 11:50 +0200
        Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Juri Lelli <juri.lelli@arm.com> - 2017-05-24 12:00 +0200
          Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 13:40 +0200
      Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Luca Abeni <luca.abeni@santannapisa.it> - 2017-05-24 12:10 +0200
        Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP  selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 13:40 +0200

csiph-web