linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>
Subject: [RFC PATCH] powerpc/powernv: Add winkle as cpuidle state
Date: Fri, 27 Nov 2015 14:06:36 +1100	[thread overview]
Message-ID: <1448593596-32329-1-git-send-email-stewart@linux.vnet.ibm.com> (raw)

This is a *very* RFC patch and one that is no doubt missing something
fairly important that I don't even know about (along with the things
that I know it's lacking).

i.e. don't merge this.

However, posting for discussion of the possibility of enabling winkle
as a cpuidle state on powernv as currently it's just used if we
hotplug out the CPU.

Using powertop with the following two patches:
https://lists.01.org/pipermail/powertop/2015-November/001852.html
https://lists.01.org/pipermail/powertop/2015-November/001854.html
also at: https://github.com/stewart-ibm/powertop/tree/power

I was able to easily measure power consumption of an idle Ubuntu 15.04
system running 4.4.0-rc2+ when idle. With the addition of this patch,
with SMT=3Doff I observed a solid 20W power saving on a dual socket 20 co=
re
system.

It seems that we have a fair few wakeups caused by IPI and dbs_timer.
There's a lot more of them with SMT=3D8 which means we spend a whole bunc=
h
less time in winkle.

After letting the machine be idle for a while, powertop was telling me
the lead causes of wakeup (SMT=3Doff) were:
              25.0 =C2=B5s/s      21.5        Interrupt      [16] IPI
              90.9 =C2=B5s/s      17.5        kWork          dbs_timer
              28.5 =C2=B5s/s       5.3        Interrupt      [3] net_rx(s=
oftirq)

Even with that though, with cores in around 50% winkle, 20W is a pretty
solid power saving that may make us want to reconsider the commonly
held wisdom that the latency of coming out of winkle isn't worth it over
just fastsleep and nap.

With some investigation as to why we're relatively often waking up, we
could get closer to the ideal situation in this workload (well, absence
of workload) in pretty much completely powering off everything but a
single core.

Note that I have *NOT* run any benchmarks on this (and we obviously want
to get the residency and latency measurements correct, likely direct
from firmware... and get them right there too).

Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
---
 drivers/cpuidle/cpuidle-powernv.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-=
powernv.c
index 845bafcfa792..50726f11ac80 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -93,6 +93,14 @@ static int fastsleep_loop(struct cpuidle_device *dev,
 	return index;
 }
 #endif
+
+static int winkle_loop(struct cpuidle_device *dev,
+				struct cpuidle_driver *drv,
+				int index)
+{
+	power7_winkle();
+	return index;
+}
 /*
  * States for dedicated partition case.
  */
@@ -235,6 +243,13 @@ static int powernv_add_idle_states(void)
 			powernv_states[nr_idle_states].enter =3D &fastsleep_loop;
 		}
 #endif
+		if (flags[i] & OPAL_PM_WINKLE_ENABLED) {
+			strcpy(powernv_states[nr_idle_states].name, "winkle");
+			strcpy(powernv_states[nr_idle_states].desc, "winkle");
+			powernv_states[nr_idle_states].flags =3D CPUIDLE_FLAG_TIMER_STOP;
+			powernv_states[nr_idle_states].target_residency =3D 3000000;
+			powernv_states[nr_idle_states].enter =3D &winkle_loop;
+		}
 		powernv_states[nr_idle_states].exit_latency =3D
 				((unsigned int)latency_ns[i]) / 1000;
=20
--=20
2.1.4

                 reply	other threads:[~2015-11-27  3:06 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1448593596-32329-1-git-send-email-stewart@linux.vnet.ibm.com \
    --to=stewart@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /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).