[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1302200311-24263-1-git-send-email-khilman@ti.com>
Date: Thu, 7 Apr 2011 11:18:31 -0700
From: Kevin Hilman <khilman@...com>
To: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-omap@...r.kernel.org
Cc: linux-pm@...ts.linux-foundation.org, Len Brown <lenb@...nel.org>,
Nicole Chalhoub <n-chalhoub@...com>,
Vincent Bour <v-bour@...com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: [PATCH] nohz: delay going tickless under CPU load to favor deeper C states
From: Nicole Chalhoub <n-chalhoub@...com>
While there is CPU load, continue the periodic tick in order to give
CPUidle another opportunity to pick a deeper C-state instead of
spending potentially long idle times in a shallow C-state.
Long winded version:
When going idle with a high load average, CPUidle menu governor will
decide to pick a shallow C-state since one of the guiding principles
of the menu governor is "The busier the system, the less impact of C
states is acceptable" (taken from cpuidle/governors/menu.c.) That
makes perfect sense.
However, there are missed power-saving opportunities for bursty
workloads with long idle times (e.g. MP3 playback.) Given such a
workload, because of the load average, CPUidle tends to pick a shallow
C-state. Because we also go tickless, this shallow C-state is used
for the duration of the idle period. If the idle period is long, a
deeper C state would've resulted in better power savings.
This patch delays going tickless when there is a load such that on the
next tick, the CPUidle governor will have another opportunity to to
pick a deeper C-state. Since the system will have been idle for
potentially a full tick, the load average will drop and a deeper C
state will most likely be chosen.
Delaying NOHZ decisions until the load is zero improved the load
estimation on our ARM/OMAP4 platform where HZ=128 and increased the
time spent in deep C-states (~50% of idle time in C-states deeper than
C1). A power saving of ~20mA at battery level is observed during MP3
playback on OMAP4/Blaze board.
Signed-off-by: Nicole Chalhoub <n-chalhoub@...com>
Signed-off-by: Vincent Bour <v-bour@...com>
Cc: Arjan van de Ven <arjan@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
[khilman@...com: rework changelog]
Signed-off-by: Kevin Hilman <khilman@...com>
---
kernel/time/tick-sched.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index d5097c4..418066c 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -324,7 +324,7 @@ void tick_nohz_stop_sched_tick(int inidle)
} while (read_seqretry(&xtime_lock, seq));
if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) ||
- arch_needs_cpu(cpu)) {
+ arch_needs_cpu(cpu) || this_cpu_load()) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
} else {
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists