From: "Doug Smythies" <dsmythies@telus.net>
To: 'Rik van Riel' <riel@redhat.com>,
"'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc: '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, '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: Wed, 9 Mar 2016 15:03:37 -0800 [thread overview]
Message-ID: <002d01d17a57$ec417030$c4c45090$@net> (raw)
In-Reply-To: <87a8m74mcc.fsf@iki.fi>
Does the direction that this thread has taken mean that those two
commits that Arto identified might now not be reverted?
Commits:
9c4b2867ed7c8c8784dd417ffd16e705e81eb145
a9ceb78bc75ca47972096372ff3d48648b16317a
Recall that increased energy consumption was also isolated to those
two commits for some types of workflow. The suggestion is that the
commits should be reverted anyhow.
What seems to be happening is that CPUs are deciding to stay in idle
state 0 a lot more, when they actually could / should be in a deeper
idle state.
Test time is always: 33 minutes and 20 seconds test (8 CPUs), and there
is never any noticeable difference in execution times for the work:
Example 1: kernel 4.5-rc5 with the rjw 3 patch set version 10
"Replace timers with utilization update callbacks":
Aggregate times in each idle state:
rjwv10 (minutes) reverted (minutes) Idle State
27.0654211 2.617325533 0
12.92451315 24.53266672 1
3.668558467 3.780482633 2
1.2727832 1.61352195 3
130.8342596 141.2234947 4
175.7655355 173.7674915 total
Example 2: kernel 4.5-rc7 stock:
Aggregate times in each idle state:
k45rc7 (minutes) reverted (minutes) Idle State
20.1771917 2.638311483 0
13.02770225 21.81474838 1
3.428136783 3.951405 2
1.4540243 1.552488167 3
134.9057413 143.5533 4
172.9927963 173.5102531 total
Energy (restated from a previous e-mail):
Test 7: reverted: Package Joules: 47830
Test 8: rjwv10: Package Joules: 54419 (revert saves 12.1% energy)
Test 9: reverted: Package Joules: 49326
Test 10: rjwv10: Package Joules: 55442 (revert saves 11% energy)
Test 11: reverted: acpi-cpufreq ondemand: Package Joules: 49146
Test 12: rjwv10: acpi-cpufreq ondemand: Package Joules: 56302 (revert saves 12.7% energy)
Energy (not in any previous e-mail):
Reverted: 56178 Joules
Kernel 4.5-rc7: 63269 Joules (revert saves 12.6% energy)
Note 1: The test computer was rebuilt in between old and new tests,
so the baseline energy may have changed.
Note 2: Unless otherwise stated, intel_pstate driver, powersave governor.
... Doug
next prev parent reply other threads:[~2016-03-09 23:03 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 [this message]
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
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='002d01d17a57$ec417030$c4c45090$@net' \
--to=dsmythies@telus.net \
--cc=lenb@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=riel@redhat.com \
--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).