[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2676200.jfxhmTd764@kreacher>
Date: Fri, 02 Aug 2019 11:28:24 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Len Brown <lenb@...nel.org>,
Linux PM <linux-pm@...r.kernel.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
"v4 . 18+" <stable@...r.kernel.org>,
Doug Smythies <doug.smythies@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 2/2] cpufreq: intel_pstate: Implement ->resolve_freq()
On Friday, August 2, 2019 11:17:55 AM CEST Rafael J. Wysocki wrote:
> On Fri, Aug 2, 2019 at 7:44 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >
> > Intel pstate driver exposes min_perf_pct and max_perf_pct sysfs files,
> > which can be used to force a limit on the min/max P state of the driver.
> > Though these files eventually control the min/max frequencies that the
> > CPUs will run at, they don't make a change to policy->min/max values.
>
> That's correct.
>
> > When the values of these files are changed (in passive mode of the
> > driver), it leads to calling ->limits() callback of the cpufreq
> > governors, like schedutil. On a call to it the governors shall
> > forcefully update the frequency to come within the limits.
>
> OK, so the problem is that it is a bug to invoke the governor's ->limits()
> callback without updating policy->min/max, because that's what
> "limits" mean to the governors.
>
> Fair enough.
AFAICS this can be addressed by adding PM QoS freq limits requests of each CPU to
intel_pstate in the passive mode such that changing min_perf_pct or max_perf_pct
will cause these requests to be updated.
Powered by blists - more mailing lists