From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754263AbcCTGyu (ORCPT ); Sun, 20 Mar 2016 02:54:50 -0400 Received: from cmta8.telus.net ([209.171.16.81]:49862 "EHLO cmta8.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbcCTGyl (ORCPT ); Sun, 20 Mar 2016 02:54:41 -0400 X-Authority-Analysis: v=2.1 cv=APo7pnY9 c=1 sm=2 tr=0 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=IkcTkHD0fZMA:10 a=QyXUC8HyAAAA:8 a=VwQbUJbxAAAA:8 a=yNTIWZF6P0BXWOFEFWAA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=P8D9QcuyWQ0bKcdb:21 a=vtuqhXuw5XpOpE9v:21 a=QEXdDO2ut3YA:10 X-Telus-Outbound-IP: 173.180.45.4 From: "Doug Smythies" To: "'Rafael J. Wysocki'" Cc: "'Rik van Riel'" , "'Linux PM list'" , "'Linux Kernel Mailing List'" References: <11672478.oHFBPvKbda@vostro.rjw.lan> In-Reply-To: <11672478.oHFBPvKbda@vostro.rjw.lan> Subject: RE: [PATCH] cpuidle: menu: Fall back to polling if next timer event is near Date: Sat, 19 Mar 2016 23:54:39 -0700 Message-ID: <000c01d18275$60543190$20fc94b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdGCP9d4fMajypWLRuu/JhXT0ENKzAAMcOog Content-Language: en-ca Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > > 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