Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1646729
| From | Viresh Kumar <viresh.kumar@linaro.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns |
| Date | 2017-05-22 13:00 +0200 |
| Message-ID | <tJTe9-4Fe-1@gated-at.bofh.it> (permalink) |
| References | <tJNV7-1ed-3@gated-at.bofh.it> <tJT4u-4AD-25@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 22-05-17, 11:45, Brendan Jackman wrote: > Hi Viresh, > > On Mon, May 22 2017 at 05:10, Viresh Kumar wrote: > > The rate_limit_us for the schedutil governor is getting set to 500 ms by > > default for the ARM64 hikey board. And its way too much, even for the > > default value. Lets set the default transition_delay_ns to something > > more realistic (10 ms), while the userspace always have a chance to set > > something it wants. > > Just a thought - do you think we can treat the reported transition > latency as a proxy for the "cost" of freq transitions? I.e. assume that > on platforms with very fast frequency switching it's probably cheap to > switch frequency and we want schedutil to respond quickly, whereas on > platforms with big latencies, frequency switches might be expensive and > we probably want hysteresis. > > If that makes sense then maybe we could use 10 * transition_latency / > NSEC_PER_USEC, when transition_latency is reported? Otherwise 10ms seems > sensible to me.. So my platform (hikey) does provide transition-latency as 500 us. But schedutil multiplies that with LATENCY_MULTIPLIER (1000) and that makes it 500000 rate_limit_us, which is unacceptable. @Rafael: Why does the LATENCY_MULTIPLIER has such a high value? I am not sure I understood completely on why we have this multiplier :( -- viresh
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] cpufreq: dt: Set default policy->transition_delay_ns Viresh Kumar <viresh.kumar@linaro.org> - 2017-05-22 07:20 +0200
Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns Brendan Jackman <brendan.jackman@arm.com> - 2017-05-22 12:50 +0200
Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns Viresh Kumar <viresh.kumar@linaro.org> - 2017-05-22 13:00 +0200
Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns Leo Yan <leo.yan@linaro.org> - 2017-05-22 13:20 +0200
Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns Viresh Kumar <viresh.kumar@linaro.org> - 2017-05-22 13:30 +0200
csiph-web