From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Doug Smythies <dsmythies@telus.net>,
"'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: 'Linux Kernel Mailing List' <linux-kernel@vger.kernel.org>,
'Linux PM list' <linux-pm@vger.kernel.org>
Subject: Re: [RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support
Date: Tue, 01 Nov 2016 17:14:23 -0700 [thread overview]
Message-ID: <1478045663.3655.4.camel@linux.intel.com> (raw)
In-Reply-To: <001301d23484$7a57fd80$6f07f880$@net>
On Tue, 2016-11-01 at 14:11 -0700, Doug Smythies wrote:
> On 2016.10.22 17:17 Rafael J. Wysocki wrote:
>
> >
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > There may be reasons to use generic cpufreq governors (eg.
> > schedutil)
> > on Intel platforms instead of the intel_pstate driver's internal
> > governor. However, that currently can only be done by disabling
> > intel_pstate altogether and using the acpi-cpufreq driver instead
> > of it, which is subject to limitations.
> >
> > First of all, acpi-cpufreq only works on systems where the _PSS
> > object is present in the ACPI tables for all logical CPUs. Second,
> > on those systems acpi-cpufreq will only use frequencies listed by
> > _PSS which may be suboptimal. In particular, by convention, the
> > whole turbo range is represented in _PSS as a single P-state and
> > the frequency assigned to it is greater by 1 MHz than the greatest
> > non-turbo frequency listed by _PSS. That may confuse governors to
> > use turbo frequencies less frequently which may lead to suboptimal
> > performance.
> >
> > For this reason, make it possible to use the intel_pstate driver
> > with generic cpufreq governors as a "normal" cpufreq driver. That
> > mode is enforced by adding intel_pstate=passive to the kernel
> > command line and cannot be disabled at run time. In that mode,
> > intel_pstate provides a cpufreq driver interface including
> > the ->target() and ->fast_switch() callbacks and is listed in
> > scaling_driver as "intel_cpufreq".
>
> It is not clear to me why users that currently use
> intel_pstate=disable on the kernel command line would benefit from
> this change.
Two reasons I think:
- We have a big turbo zone, where current acpi-cpufreq can't select any
target frequency even if controllable.
- We can still target ACPI-CPPC compatible devices in legacy mode and
later in non-legacy mode.
Thanks,
Srinivas
next prev parent reply other threads:[~2016-11-02 0:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-01 21:11 [RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support Doug Smythies
2016-11-02 0:14 ` Srinivas Pandruvada [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-10-23 0:17 Rafael J. Wysocki
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=1478045663.3655.4.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.