From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Huaisheng HS1 Ye <yehs1@lenovo.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "lenb@kernel.org" <lenb@kernel.org>,
"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: intel_pstate: Fix cpuinfo_cur_freq after performance governor changes
Date: Mon, 24 Jul 2017 19:57:45 -0700 [thread overview]
Message-ID: <1500951465.4920.2.camel@linux.intel.com> (raw)
In-Reply-To: <KL1PR0302MB2502DDDCC1D0F4FCC2916B4392B80@KL1PR0302MB2502.apcprd03.prod.outlook.com>
On Tue, 2017-07-25 at 01:46 +0000, Huaisheng HS1 Ye wrote:
> Hi Rafael,
>
> If you delete "get" function implement within intel_pstate, the
> sysfs interface cpuinfo_cur_freq will display <unknown> all the
> time.
cpuinfo_cur_freq by definition should show actual frequency HW
frequency. Unless I missed something. So Len Brown's patch should also
take care of this to get from arch specific function is available.
So in addition to Rafael's change, what about this?
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 9bf97a3..29ec687 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -689,8 +689,13 @@ store_one(scaling_max_freq, max);
static ssize_t show_cpuinfo_cur_freq(struct cpufreq_policy *policy,
char *buf)
{
- unsigned int cur_freq = __cpufreq_get(policy);
+ unsigned int cur_freq;
+ cur_freq = arch_freq_get_on_cpu(policy->cpu);
+ if (cur_freq)
+ return sprintf(buf, "%u\n", cur_freq);
+
+ cur_freq = __cpufreq_get(policy);
if (cur_freq)
return sprintf(buf, "%u\n", cur_freq);
Thanks,
Srinivas
> To be honest, at the beginning I have consider this way like you
> patched, but based two reasons below, it is conservative for us to do
> that.
>
> 1. I am worried about whether it would lead to confusion for
> customers or
> Linux OS venders who are accustomed to cpuinfo_cur_freq.
> 2. This is the first time for me to offer patch to intel_pstate, not
> sure
> whether it could be accepted by you.
>
> >
> > On Monday, July 24, 2017 03:32:47 PM Huaisheng HS1 Ye wrote:
> > >
> > > Hi Rafael,
> > > Thanks for your reply.
> > >
> > > >
> > > > On Monday, July 24, 2017 05:43:14 AM Huaisheng HS1 Ye wrote:
> > > > >
> > > > > After commit 82b4e03e01bc (intel_pstate: skip scheduler hook
> > > > > when
> > > > > in "performance" mode) Software P-state control modes
> > > > > couldn't get
> > > > > dynamic value during performance mode,
> > > > Please explain what you mean here.
> > > >
> > > commit 82b4e03e01bc (intel_pstate: skip scheduler hook when in
> > > "performance" mode) disables intel_pstate_set_update_util_hook
> > > when
> > > current policy is performance within function
> > > intel_pstate_set_policy.
> > > It leads to Software P-states couldn't update sysfs interface
> > > cpuinfo_cur_freq's value during performance mode, because of
> > > pstate_funcs.update_util couldn't set for the given CPU.
> > >
> > > >
> > > > I guess you carried out some tests and the results were not as
> > > > expected, so what was the test?
> > > Exactly, we check the sysfs interface cpuinfo_cur_freq and the
> > > output
> > > of cpupower frequency-info both with performance mode.
> > OK, so what about the change below:
> >
> > ---
> > drivers/cpufreq/intel_pstate.c | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > Index: linux-pm/drivers/cpufreq/intel_pstate.c
> > ==============================================================
> > =====
> > --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> > +++ linux-pm/drivers/cpufreq/intel_pstate.c
> > @@ -1674,13 +1674,6 @@ static int intel_pstate_init_cpu(unsigne
> > return 0;
> > }
> >
> > -static unsigned int intel_pstate_get(unsigned int cpu_num) -{
> > - struct cpudata *cpu = all_cpu_data[cpu_num];
> > -
> > - return cpu ? get_avg_frequency(cpu) : 0;
> > -}
> > -
> > static void intel_pstate_set_update_util_hook(unsigned int
> > cpu_num) {
> > struct cpudata *cpu = all_cpu_data[cpu_num]; @@ -1921,7
> > +1914,6 @@
> > static struct cpufreq_driver intel_pstat
> > .setpolicy = intel_pstate_set_policy,
> > .suspend = intel_pstate_hwp_save_state,
> > .resume = intel_pstate_resume,
> > - .get = intel_pstate_get,
> > .init = intel_pstate_cpu_init,
> > .exit = intel_pstate_cpu_exit,
> > .stop_cpu = intel_pstate_stop_cpu,
next prev parent reply other threads:[~2017-07-25 2:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 5:43 [PATCH] cpufreq: intel_pstate: Fix cpuinfo_cur_freq after performance governor changes Huaisheng HS1 Ye
2017-07-24 11:36 ` Rafael J. Wysocki
2017-07-24 15:32 ` Huaisheng HS1 Ye
2017-07-24 23:51 ` Rafael J. Wysocki
2017-07-25 1:46 ` Huaisheng HS1 Ye
2017-07-25 2:57 ` Srinivas Pandruvada [this message]
2017-07-25 7:03 ` Huaisheng HS1 Ye
2017-07-25 14:37 ` Srinivas Pandruvada
2017-07-25 15:22 ` Huaisheng HS1 Ye
2017-07-25 21:46 ` Rafael J. Wysocki
2017-07-25 15:35 ` Rafael J. Wysocki
2017-07-25 22:42 ` [PATCH] cpufreq: intel_pstate: Drop ->get from intel_pstate structure Rafael J. Wysocki
2017-07-27 3:47 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1500951465.4920.2.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
--cc=yehs1@lenovo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox