From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: 'Srinivas Pandruvada' <srinivas.pandruvada@linux.intel.com>,
'LKML' <linux-kernel@vger.kernel.org>,
'Linux PM' <linux-pm@vger.kernel.org>,
'Doug Smythies' <dsmythies@telus.net>
Subject: RE: [Update][PATCH v3 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy
Date: Wed, 29 Mar 2017 15:16:04 -0700 [thread overview]
Message-ID: <004201d2a8da$12e74910$38b5db30$@net> (raw)
In-Reply-To: tLegcUXspnsYHtLehcsgkR
Hi Rafael,
Disregard.
I see this was fixed in kernel 4.11-rc4.
While kernel 4.11-rc4 was where I thought I started from earlier,
actually I was running 4.11-rc2 at the time.
sorry for the noise.
On 2017.03.29 15:01 Doug Smythies wrote:
> Sorry for the delay, but I didn't notice until today that this
> commit causes a regression, at least in my computer.
>
> I have not figured out exactly what is wrong, as I must
> admit I am finding these policy interactions difficult
> to follow.
>
> On 2017.03.02 14:29 Rafael J. Wysocki wrote:
>>From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> If the current P-state selection algorithm is set to "performance"
>> in intel_pstate_set_policy(), the limits may be initialized from
>
> ... [cut] ...
>
> Going back to kernel 4.11-rc1 I get this after boot**:
>
> $ uname -a
> Linux s15 4.11.0-rc1-stock #217 SMP Sun Mar 5 15:34:38 PST 2017 x86_64 x86_64 x86_64 GNU/Linux
next prev parent reply other threads:[~2017-03-29 22:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-28 13:13 [PATCH 0/2] cpufreq: intel_pstate: Two fixes related to limis Rafael J. Wysocki
2017-02-28 13:14 ` [PATCH 1/2] cpufreq: intel_pstate: Fix global settings in active mode Rafael J. Wysocki
2017-02-28 22:21 ` Rafael J. Wysocki
2017-02-28 13:16 ` [PATCH 2/2] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy Rafael J. Wysocki
2017-02-28 23:00 ` [PATCH v2 0/3] cpufreq: intel_pstate: Fixes related to limis Rafael J. Wysocki
2017-02-28 23:07 ` [PATCH v2 1/3] cpufreq: intel_pstate: Fix global settings in active mode Rafael J. Wysocki
2017-02-28 23:09 ` [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy Rafael J. Wysocki
2017-03-02 17:18 ` Rafael J. Wysocki
2017-03-02 17:22 ` Rafael J. Wysocki
2017-03-02 22:29 ` [Update][PATCH v3 " Rafael J. Wysocki
2017-03-29 22:01 ` Doug Smythies
2017-03-29 22:16 ` Doug Smythies [this message]
2017-03-29 22:17 ` Rafael J. Wysocki
2017-02-28 23:11 ` [PATCH v2 3/3] cpufreq: intel_pstate: Fix intel_pstate_verify_policy() 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='004201d2a8da$12e74910$38b5db30$@net' \
--to=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.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 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.