All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Doug Smythies <dsmythies@telus.net>
Cc: "'Thomas Ilsche'" <thomas.ilsche@tu-dresden.de>,
	"'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>
Subject: Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework
Date: Wed, 21 Mar 2018 07:33:21 +0100	[thread overview]
Message-ID: <1690803.hdDb2ySb37@aspire.rjw.lan> (raw)
In-Reply-To: <002d01d3c08e$f43aa750$dcaff5f0$@net>

On Tuesday, March 20, 2018 10:03:50 PM CET Doug Smythies wrote:
> Summary: My results with kernel 4.16-rc6 and V8 of the patch set
> are completely different, and now show no clear difference
> (a longer test might reveal something). 

Does this mean that you see the "powernightmares" pattern with the v8
again or are you referring to something else?

> On 2018.03.20 10:16 Doug Smythies wrote:
> > 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

Would it be possible to produce this graph with the v8 of the
patchset?

> > 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
> 
> Now, with kernel 4.16-rc6 and V8 of the patch set and the poll fix
> I am unable to measure the processor package power difference
> between idle state 0 enabled or disabled (i.e. it is in the noise).
> also the loop time changes (overhead changes) are minimal. However,
> the overall loop time has dropped to ~2730 Hz, so there seems to be
> a little more overhead in general.
> 
> I increased my loop frequency to ~3316 Hz. Similar.
> 
> I increased my loop frequency to ~15474 Hz. Similar.
> Compared to a stock 4.16-rc6 kernel: The loop rate dropped
> to 15,209 Hz and it (the stock kernel) used about 0.3 more
> watts (out of 10.97, or ~3% more).

So do you prefer v6 or v8?  I guess the former?

  reply	other threads:[~2018-03-21  6:32 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
2018-03-20 21:03       ` Doug Smythies
2018-03-21  6:33         ` Rafael J. Wysocki [this message]
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=1690803.hdDb2ySb37@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=aubrey.li@linux.intel.com \
    --cc=dsmythies@telus.net \
    --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 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.