From: "Doug Smythies" <dsmythies@telus.net>
To: "'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
'Rik van Riel' <riel@redhat.com>
Cc: "'Rafael J. Wysocki'" <rafael@kernel.org>,
'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: [PATCH] cpuidle: use high confidence factors only when considering polling
Date: Thu, 17 Mar 2016 23:32:09 -0700 [thread overview]
Message-ID: <000701d180df$e8a14340$b9e3c9c0$@net> (raw)
In-Reply-To: <10828426.sI6CaBvZhk@vostro.rjw.lan>
Sorry for the delay in my reply / test. The patch e-mail went
to my junk folder for some reason.
On 2106.03.17 17:46 Rafael J. Wysocki wrote:
> On Wednesday, March 16, 2016 12:14:00 PM Rik van Riel wrote:
>> The menu governor uses five different factors to pick the
>> idle state:
>> - the user configured latency_req
>> - the time until the next timer (next_timer_us)
>> - the typical sleep interval, as measured recently
>> - an estimate of sleep time by dividing next_timer_us by an observed factor
>> - a load corrected version of the above, divided again by load
>>
>> Only the first three items are known with enough confidence that
>> we can use them to consider polling, instead of an actual CPU
>> idle state, because the cost of being wrong about polling can be
>> excessive power use.
>>
>> The latter two are used in the menu governor's main selection
>> loop, and can result in choosing a shallower idle state when
>> the system is expected to be busy again soon.
>>
>> This pushes a busy system in the "performance" direction of
>> the performance<>power tradeoff, when choosing between idle
>> states, but stays more strictly on the "power" state when
>> deciding between polling and C1.
>>
>> Signed-off-by: Rik van Riel <riel@redhat.com>
For my part of it, this patch seems to be not O.K.
(reference rvr5 = this patch)
Aggregate idle for the 2000 second test. All in minutes.
(old tests re-stated)
State k45rc7-rjw10 k45rc7-rjw10-reverted k45rc7-rjw10-rvr5
0.00 18.07 0.92 18.67
1.00 12.35 19.51 12.82
2.00 3.96 4.28 3.97
3.00 1.55 1.53 1.58
4.00 138.96 141.99 143.80
total 174.90 168.24 180.84
Energy:
>> Kernel 4.5-rc7-rjw10: 61983 Joules
>> Kernel 4.5-rc7-rjw10-reverted: 48409 Joules (test 2 was 55040 Joules)
Kernel 4.5-rc7-rjw10-rvr5: 62243 Joules
I did acquire trace data with this test, but haven't post processed it yet.
... Doug
next prev parent reply other threads:[~2016-03-18 6:32 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
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 [this message]
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='000701d180df$e8a14340$b9e3c9c0$@net' \
--to=dsmythies@telus.net \
--cc=lenb@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@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 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.