From: Nicole Chalhoub <[email protected]> One criterion of C-states selection is based on the load factor. High load prevents deep C-states. The load is evaluated and updated at each scheduler tick, and thus not updated when in tickless mode. As a result, the CPU load calculated on the tick just before entering tickless is used for idle decisions.
When a high load is evaluated on a tick happening on a burst of activity, this load value is kept until the next tick, which could take few ms to happen if going tickless. This patch ensures that the load is taken into consideration before going tickless. Rather than going tickless and entering a shallow sleep state, the decison to go tickless is slightly delayed so that the idle governor will tend to favor deeper sleep states. 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 <[email protected]> Signed-off-by: Vincent Bour <[email protected]> Cc: Arjan van de Ven <[email protected]> Cc: Thomas Gleixner <[email protected]> [[email protected]: minor edits/changes to changelog] Signed-off-by: Kevin Hilman <[email protected]> --- Applies to v2.6.38-rc2 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 3e216e0..96cb512 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -325,7 +325,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.3.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
