From: "Doug Smythies" <dsmythies@telus.net>
To: "'Thomas Ilsche'" <thomas.ilsche@tu-dresden.de>
Cc: "'Linux PM'" <linux-pm@vger.kernel.org>,
"'Frederic Weisbecker'" <fweisbec@gmail.com>,
"'Thomas Gleixner'" <tglx@linutronix.de>,
"'Paul McKenney'" <paulmck@linux.vnet.ibm.com>,
"'Rik van Riel'" <riel@surriel.com>,
"'Aubrey Li'" <aubrey.li@linux.intel.com>,
"'Mike Galbraith'" <mgalbraith@suse.de>,
"'LKML'" <linux-kernel@vger.kernel.org>,
"'Peter Zijlstra'" <peterz@infradead.org>,
"'Rafael J. Wysocki'" <rafael@kernel.org>,
"Doug Smythies" <dsmythies@telus.net>
Subject: RE: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework
Date: Tue, 20 Mar 2018 10:15:30 -0700 [thread overview]
Message-ID: <002501d3c06f$0e7cf750$2b76e5f0$@net> (raw)
In-Reply-To: yE6GempwD1KonyE6LeVquN
On 2018.03.20 03:02 Thomas Ilsche wrote:
...[snip]...
> Consider the Skylake server system which has residencies in C1E of
> 20 us and C6 of 800 us. I use a small while(1) {usleep(300);}
> unsynchronized pinned to each core. While this is an artificial
> case, it is a very innocent one - easy to predict and regular. Between
> vanilla 4.16.0-rc5 and idle-loop/v6, the power consumption increases
> from 149.7 W to 158.1 W. On 4.16.0-rc5, the cores sleep almost
> entirely in C1E. With the patches applied, the cores spend ~75% of
> their sleep time in C6, ~25% in C1E. The average time/usage for C1E is
> also lower with v6 at ~350 us rather than the ~550 us in C6 (and in
> C1E with the baseline). Generally the new menu governor seems to chose
> C1E if the next timer is an enabled sched timer - which occasionally
> interrupts the sleep-interval into two C1E sleeps rather than one C6.
>
> Manually disabling C6, reduces power consumption back to 149.5 W.
...[snip]...
Note that one of the tests that I normally do is a work/sleep
frequency sweep from 100 to 2100 Hz, typically at a lowish
workload. I didn't notice anything odd with this test:
http://fast.smythies.com/rjw_freq_sweep.png
However, your test is at 3333 Hz (well, minus overheads).
I did the same as you. And was surprised to confirm
your power findings. In my case package power goes from
~8.6 watts to ~7.3 watts with idle state 4 (C6) disabled.
I am getting different residency times than you though.
I also observe different overheads between idle state 4
being disabled or not. i.e. my actual loop frequency
drops from ~2801 Hz to ~2754 Hz.
Example residencies over the previous minute:
Idle state 4 (C6) disabled (seconds):
Idle state 0: 0.001119
Idle state 1: 0.056638
Idle state 2: 13.100550
Idle state 3: 446.266744
Idle state 4: 0.000000
Idle state 4 (C6) enabled (seconds):
Idle state 0: 0.034502
Idle state 1: 1.949595
Idle state 2: 78.291793
Idle state 3: 96.467974
Idle state 4: 286.247524
... Doug
next prev parent reply other threads:[~2018-03-20 17:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 21:59 [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Rafael J. Wysocki
2018-03-15 22:03 ` [RFT][PATCH v5 1/7] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-15 22:05 ` [RFT][PATCH v5 2/7] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-15 22:07 ` [RFT][PATCH v5 3/7] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-15 22:11 ` [RFT][PATCH v5 4/7] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-19 9:11 ` Peter Zijlstra
2018-03-19 9:39 ` Rafael J. Wysocki
2018-03-15 22:13 ` [RFT][PATCH v5 5/7] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-15 22:16 ` [RFT][PATCH v5 6/7] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-03-19 9:45 ` Peter Zijlstra
2018-03-19 9:49 ` Rafael J. Wysocki
2018-03-15 22:19 ` [RFT][PATCH v5 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick Rafael J. Wysocki
2018-03-19 12:47 ` Thomas Ilsche
2018-03-19 18:21 ` Doug Smythies
2018-03-20 17:15 ` Doug Smythies
2018-03-20 17:28 ` Rafael J. Wysocki
2018-03-17 12:42 ` [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Thomas Ilsche
2018-03-17 16:11 ` Doug Smythies
2018-03-18 11:00 ` Rafael J. Wysocki
2018-03-18 16:15 ` Rafael J. Wysocki
2018-03-19 10:49 ` Peter Zijlstra
2018-03-19 11:36 ` Rafael J. Wysocki
2018-03-19 11:58 ` Rafael J. Wysocki
2018-03-19 12:31 ` Peter Zijlstra
2018-03-20 10:01 ` Thomas Ilsche
2018-03-20 10:49 ` Rafael J. Wysocki
2018-03-20 17:15 ` Doug Smythies [this message]
2018-03-20 21:03 ` Doug Smythies
2018-03-21 6:33 ` Rafael J. Wysocki
2018-03-21 13:51 ` Doug Smythies
2018-03-21 13:58 ` Rafael J. Wysocki
2018-03-18 15:30 ` Doug Smythies
2018-03-18 16:06 ` 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='002501d3c06f$0e7cf750$2b76e5f0$@net' \
--to=dsmythies@telus.net \
--cc=aubrey.li@linux.intel.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=thomas.ilsche@tu-dresden.de \
/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