Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1524092 > unrolled thread
| Started by | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| First post | 2016-11-17 06:30 +0100 |
| Last post | 2016-11-21 22:00 +0100 |
| Articles | 2 on this page of 22 — 6 participants |
Back to article view | Back to linux.kernel
[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
Page 2 of 2 — ← Prev page 1 [2]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-11-21 17:50 +0100 |
| Subject | Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits |
| Message-ID | <sFZX3-3Fn-7@gated-at.bofh.it> |
| In reply to | #1526872 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2016-11-21 22:00 +0100 |
| Message-ID | <sG3R5-67C-7@gated-at.bofh.it> |
| In reply to | #1526900 |
On Mon, Nov 21, 2016 at 5:46 PM, Peter Zijlstra <peterz@infradead.org> wrote: > 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. We don't use the IIR filter in intel_pstate after all. We evaluated it, but it affected performance too much to be useful for us. That said in the "proportional" version of the intel_pstate's P-state selection algorithm (without PID) we ramp up faster than we reduce the P-state, but the approach used in there depends on using the feedback registers. And, of course, that's only used if HWP is not active. Thanks, Rafael
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web