From: Rik van Riel <riel@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Doug Smythies <dsmythies@telus.net>,
Viresh Kumar <viresh.kumar@linaro.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
"Chen, Yu C" <yu.c.chen@intel.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Arto Jantunen <viiru@iki.fi>, Len Brown <lenb@kernel.org>
Subject: Re: SKL BOOT FAILURE unless idle=nomwait (was Re: PROBLEM: Cpufreq constantly keeps frequency at maximum on 4.5-rc4)
Date: Tue, 15 Mar 2016 20:55:21 -0400 [thread overview]
Message-ID: <1458089721.8898.25.camel@redhat.com> (raw)
In-Reply-To: <2600831.Qfymhh5Hpv@vostro.rjw.lan>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Wed, 2016-03-16 at 01:32 +0100, Rafael J. Wysocki wrote:
>
> * We want to default to C1 (hlt), not to busy
> polling
> - * unless the timer is happening really really soon.
> + * unless the timer is happening really really
> soon. Still, if
> + * the exit latency of C1 is too high, we need to
> poll anyway.
> */
> - if (interactivity_req > 20 &&
> + if (data->next_timer_us > 20 &&
> + drv-
> >states[CPUIDLE_DRIVER_STATE_START].exit_latency <= 2 &&
> !drv-
I wonder if replacing these two tests with
data->next_timer_us
> states[CPUIDLE_DRIVER_STATE_START].exit_latency
would do the right thing?
That way any time we do not know for sure we are waking
up before the HLT exit latency has gone, we will poll.
Any time we suspect we will wake up sooner (data->predicted_us
is smaller than the HLT exit latency) we will still pick HLT,
anyway.
This makes the behaviour consistent between CPUs.
> >states[CPUIDLE_DRIVER_STATE_START].disabled &&
> - dev-
> >states_usage[CPUIDLE_DRIVER_STATE_START].disable == 0)
> + !dev-
> >states_usage[CPUIDLE_DRIVER_STATE_START].disable)
> data->last_state_idx =
> CPUIDLE_DRIVER_STATE_START;
> } else {
> data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-03-16 0:55 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-01 17:51 SKL BOOT FAILURE unless idle=nomwait (was Re: PROBLEM: Cpufreq constantly keeps frequency at maximum on 4.5-rc4) Len Brown
[not found] ` <87si087tsr.fsf@iki.fi>
2016-03-02 17:10 ` Rik van Riel
2016-03-08 21:13 ` Len Brown
2016-03-08 21:19 ` Len Brown
2016-03-09 17:01 ` Arto Jantunen
2016-03-09 23:03 ` Doug Smythies
2016-03-09 23:18 ` Rafael J. Wysocki
2016-03-09 23:45 ` Doug Smythies
2016-03-09 23:59 ` Rafael J. Wysocki
2016-03-11 14:03 ` Rik van Riel
2016-03-11 18:22 ` Doug Smythies
2016-03-11 20:30 ` Rik van Riel
2016-03-11 23:54 ` Rafael J. Wysocki
2016-03-12 0:46 ` Doug Smythies
2016-03-12 1:45 ` Rafael J. Wysocki
2016-03-12 2:02 ` Rafael J. Wysocki
2016-03-13 7:46 ` Doug Smythies
2016-03-14 1:32 ` Rafael J. Wysocki
2016-03-14 6:39 ` Doug Smythies
2016-03-14 12:47 ` Rafael J. Wysocki
2016-03-14 14:31 ` Rik van Riel
2016-03-14 15:21 ` Rafael J. Wysocki
2016-03-14 17:45 ` Rik van Riel
2016-03-14 22:55 ` Rafael J. Wysocki
2016-03-15 2:03 ` Rik van Riel
2016-03-16 0:32 ` Rafael J. Wysocki
2016-03-16 0:37 ` Rafael J. Wysocki
2016-03-16 0:55 ` Rik van Riel [this message]
2016-03-16 1:53 ` Rafael J. Wysocki
2016-03-16 13:02 ` Rafael J. Wysocki
2016-03-16 14:01 ` Rik van Riel
2016-03-16 14:14 ` Rafael J. Wysocki
2016-03-16 14:46 ` Rik van Riel
2016-03-16 15:05 ` Rafael J. Wysocki
2016-03-16 15:07 ` Rik van Riel
2016-03-16 15:09 ` Rafael J. Wysocki
2016-03-16 16:14 ` [PATCH] cpuidle: use high confidence factors only when considering polling Rik van Riel
2016-03-18 0:45 ` Rafael J. Wysocki
2016-03-18 6:32 ` Doug Smythies
2016-03-18 13:11 ` Rafael J. Wysocki
2016-03-18 18:32 ` Doug Smythies
2016-03-18 19:29 ` Rik van Riel
2016-03-18 20:59 ` Doug Smythies
2016-03-18 21:24 ` Rafael J. Wysocki
2016-03-18 21:26 ` Rik van Riel
2016-03-18 23:40 ` Rafael J. Wysocki
2016-03-18 21:35 ` Rik van Riel
2016-03-18 21:48 ` Rafael J. Wysocki
2016-03-18 21:52 ` Rik van Riel
2016-03-18 22:09 ` Rafael J. Wysocki
2016-03-18 22:28 ` Rik van Riel
2016-03-18 23:29 ` Rafael J. Wysocki
2016-03-18 21:56 ` Rafael J. Wysocki
2016-03-18 22:38 ` Rafael J. Wysocki
2016-03-18 22:56 ` Rafael J. Wysocki
2016-03-19 1:53 ` Rik van Riel
2016-03-19 2:06 ` Rafael J. Wysocki
2016-03-19 2:17 ` Rik van Riel
2016-03-19 2:33 ` 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=1458089721.8898.25.camel@redhat.com \
--to=riel@redhat.com \
--cc=dsmythies@telus.net \
--cc=lenb@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=viiru@iki.fi \
--cc=viresh.kumar@linaro.org \
--cc=yu.c.chen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).