linux-kernel - RE: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <000c01d18275$60543190$20fc94b0$@net>
Date:	Sat, 19 Mar 2016 23:54:39 -0700
From:	"Doug Smythies" <dsmythies@...us.net>
To:	"'Rafael J. Wysocki'" <rjw@...ysocki.net>
Cc:	"'Rik van Riel'" <riel@...hat.com>,
	"'Linux PM list'" <linux-pm@...r.kernel.org>,
	"'Linux Kernel Mailing List'" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near

On 2016.03.19 17:34 Rafael J. Wysocki wrote:

> Commit a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable
> polling) changed the behavior of the fallback state selection part
> of menu_select() so it looks at interactivity_req instead of
> data->next_timer_us when it makes its decision.  That effectively
> caused polling to be used more often as fallback idle which led to
> significant increases of energy consumption in some cases.
>
> Commit e132b9b3bc7f (cpuidle: menu: use high confidence factors
> only when considering polling) changed that logic again to be more
> predictable, but that didn't help with the increased energy
> consumption problem.
>
> For this reason, go back to making decisions on which state to fall
> back to based on data->next_timer_us which is the time we know for
> sure something will happen rather than a prediction (which may be
> inaccurate and turns out to be so often enough to be problematic).
> However, take the target residency of the first proper idle state
> (C1) into account, so that state is not used as the fallback one
> if its target residency is greater than data->next_timer_us.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> ---
> 
> Doug, can you please see if this patch helps to address the problem
> you're seeing?
> 

Yes, it appears to work great.

>
> Commit e132b9b3bc7f is in linux-next only ATM, but it is a rebased
> version of https://patchwork.kernel.org/patch/8602101/.

So, I applied it to my existing kernel 4.5-rc7 work, i.e. the not
rebased version.

My reference = rvr7:
Kernel 4.5-rc7 +
Rafael's 3 patch set version 10 "cpufreq: Replace timers with utilization update callbacks" +
Rik's patch (rvr5) "cpuidle: menu: use high confidence factors only when considering polling" +
Rafael's patch from herein.

My reference: k45rc7-rjw10-rvr7

Aggregate Idle States in minutes for 2000 second test (some old data re-stated for reference):

State	k45rc7-rjw10	k45rc7-rjw10-reverted	k45rc7-rjw10-rvr7
0.00	18.07			0.92				0.41
1.00	12.35			19.51				21.17
2.00	3.96			4.28				4.40
3.00	1.55			1.53				1.66
4.00	138.96		141.99			150.77
			
total	174.90		168.24			178.41

Energy:
>>>> Kernel 4.5-rc7-rjw10: 61983 Joules
>>>> Kernel 4.5-rc7-rjw10-reverted: 48409 Joules (test 2 was 55040 Joules)
k45rc7-rjw10-rvr7: 54748 Joules

The trace data has a record low number of long durations at 71.

... Doug