[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3617293.cCXa2uXImB@aspire.rjw.lan>
Date: Wed, 28 Jun 2017 22:52:53 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Leo Yan <leo.yan@...aro.org>,
Brendan Jackman <brendan.jackman@....com>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux PM <linux-pm@...r.kernel.org>,
Amit Kucheria <amit.kucheria@...aro.org>
Subject: Re: [PATCH] cpufreq: dt: Set default policy->transition_delay_ns
On Wednesday, June 28, 2017 09:44:55 AM Viresh Kumar wrote:
> On 27-06-17, 18:08, Rafael J. Wysocki wrote:
> > On Tue, Jun 27, 2017 at 6:20 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> > > @Rafael: Will it be fine to lower down the value of LATENCY_MULTIPLIER?
> >
> > We can do that, but then I think we need to compensate for the change
> > in the old governors code or there may be surprises.
>
> Why shouldn't we change the value of LATENCY_MULTIPLIER for old
> governors as well? They use the same calculations and the sampling
> rate there is also this bad (like rate_limit_us).
On some systems. On other systems it isn't.
> If we aren't going to change that for old governors, then we can
> create a local version of LATENCY_MULTIPLIER for schedutil I believe.
OK, so at least for intel_pstate and acpi-cpufreq we want a 10 ms default
which is what we have currently.
If you want to rework all that, make sure you preserve that.
Thanks,
Rafael
Powered by blists - more mailing lists