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

Groups > linux.kernel > #1526900

Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits

Show all headers | View raw

On Mon, Nov 21, 2016 at 04:24:24PM +0000, Patrick Bellasi wrote:
> On 21-Nov 16:26, Peter Zijlstra wrote:

> > In any case, worth trying, see what happens.
> 
> Are you saying that you would like to see the code which implements a
> more generic version of the peak_util "filter" on top of PELT?

Not sure about peak_util, I was more thinking of an IIR/PID filter, as
per the email thread referenced below. Doesn't make sense to hide that
in intel_pstate if it appears to be universally useful etc.. 

> IMO it could be a good exercise now that we agree we want to improve
> PELT without replacing it.

I think it would make sense to keep it inside sched_cpufreq for now.

> > > For example, a task running 30 [ms] every 100 [ms] is a ~300 util_avg
> > > task. With PELT, we get a signal which range between [120,550] with an
> > > average of ~300 which is instead completely ignored. By capping the
> > > decay we will get:
> > > 
> > >    decay_cap [ms]      range    average
> > >                 0      120:550     300
> > >                64      140:560     310
> > >                32      320:660     430
> > > 
> > > which means that still the raw PELT signal is wobbling and never
> > > provides a consistent response to drive decisions.
> > > 
> > > Thus, a "predictor" should be something which sample information from
> > > PELT to provide a more consistent view, a sort of of low-pass filter
> > > on top of the "dynamic metric" which is PELT.
> > > 
> > > Should not such a "predictor" help on solving some of the issues
> > > related to PELT slow ramp-up or fast ramp-down?
> > 
> > I think intel_pstate recently added a local PID filter, I asked at the
> > time if something like that should live in generic code, looks like
> > maybe it should.
> 
> That PID filter is not "just" a software implementation of the ACPI's
> Collaborative Processor Performance Control (CPPC) when HWP hardware
> is not provided by a certain processor?

I think it was this thread:

  http://lkml.kernel.org/r/1572483.RZjvRFdxPx@vostro.rjw.lan

It never really made sense such a filter should live in individual
drivers.

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

Thread

[PATCH] cpufreq: schedutil: add up/down frequency transition rate limits Viresh Kumar <viresh.kumar@linaro.org> - 2016-11-17 06:30 +0100
  Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Viresh Kumar <viresh.kumar@linaro.org> - 2016-11-21 11:10 +0100
    Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 11:20 +0100
      Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Viresh Kumar <viresh.kumar@linaro.org> - 2016-11-21 11:50 +0100
        Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 12:20 +0100
          Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Viresh Kumar <viresh.kumar@linaro.org> - 2016-11-21 12:40 +0100
            Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 12:50 +0100
      Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Juri Lelli <Juri.Lelli@arm.com> - 2016-11-21 13:20 +0100
        Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 13:30 +0100
          Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Juri Lelli <Juri.Lelli@arm.com> - 2016-11-21 15:00 +0100
            Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 15:20 +0100
              Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Juri Lelli <Juri.Lelli@arm.com> - 2016-11-21 15:40 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 15:50 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Juri Lelli <Juri.Lelli@arm.com> - 2016-11-21 16:00 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits Vincent Guittot <vincent.guittot@linaro.org> - 2016-11-22 10:30 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Patrick Bellasi <patrick.bellasi@arm.com> - 2016-11-22 12:10 +0100
            Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Patrick Bellasi <patrick.bellasi@arm.com> - 2016-11-21 16:00 +0100
              Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 16:30 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 16:40 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Patrick Bellasi <patrick.bellasi@arm.com> - 2016-11-21 17:30 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition  rate limits Peter Zijlstra <peterz@infradead.org> - 2016-11-21 17:50 +0100
                Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits "Rafael J. Wysocki" <rafael@kernel.org> - 2016-11-21 22:00 +0100

csiph-web