From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751549AbcBLRCO (ORCPT ); Fri, 12 Feb 2016 12:02:14 -0500 Received: from cmta16.telus.net ([209.171.16.89]:36175 "EHLO cmta16.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750865AbcBLRCL (ORCPT ); Fri, 12 Feb 2016 12:02:11 -0500 X-Authority-Analysis: v=2.1 cv=NNsogBOg 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=JfrnYn6hAAAA:8 a=xHCL_1Teb9PCBHepsJEA:9 a=mjl7uNUmsp-WR82D:21 a=NGrq3Nju_ygcgTcC:21 a=QEXdDO2ut3YA:10 X-Telus-Outbound-IP: 173.180.45.4 From: "Doug Smythies" To: "'Rafael J. Wysocki'" , "'Peter Zijlstra'" Cc: "'Steve Muckle'" , "'Rafael J. Wysocki'" , "'Linux PM list'" , "'Linux Kernel Mailing List'" , "'Srinivas Pandruvada'" , "'Viresh Kumar'" , "'Juri Lelli'" , "'Thomas Gleixner'" References: <3071836.JbNxX8hU6x@vostro.rjw.lan> <56B93548.9090006@linaro.org> <5387313.xAhVpzgZCg@vostro.rjw.lan> <56BA8C29.4090905@linaro.org> <20160211115959.GI6357@twins.programming.kicks-ass.net> <56BCBF7C.2080404@linaro.org> <20160211173033.GP6357@twins.programming.kicks-ass.net> <56BCD864.6030207@linaro.org> <20160212141009.GT6357@twins.programming.kicks-ass.net> In-Reply-To: Subject: RE: [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks Date: Fri, 12 Feb 2016 09:02:07 -0800 Message-ID: <001501d165b7$1c69c790$553d56b0$@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: AdFlrp8x32WUA9eDSDKqQM9lMdOsRgABfMGQ Content-Language: en-ca Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016.02.12 08:01 Rafael J. Wysocki wrote: > On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote: >> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote: >>> On 02/11/2016 09:30 AM, Peter Zijlstra wrote: >>>>> My concern above is that pokes are guaranteed to keep occurring when >>>>> there is only RT or DL activity so nothing breaks. >>>> >>>> The hook in their respective tick handler should ensure stuff is called >>>> sporadically and isn't stalled. >>> >>> But that's only true if the RT/DL tasks happen to be running when the >>> tick arrives right? >>> >>> Couldn't we have RT/DL activity which doesn't overlap with the tick? And >>> if no CFS tasks happen to be executing on that CPU, we'll never trigger >>> the cpufreq update. This could go on for an arbitrarily long time >>> depending on the periodicity of the work. >> >> Possible yes, but why do we care? Such a CPU would be so much idle that >> cpufreq doesn't matter one way or another, right? > Well, in theory you can get 50% or so of the time active in bursts > that happen to fit between ticks. If we happen to do those in the > lowest P-state, we may burn more energy than necessary on platforms > where more idle is preferred. I believe this happens considerably more often than is commonly thought, and is the exact reason I was opposed to the introduction of the "duration" method into the intel_pstate driver in the first place. The probability of occurrence (of a relatively busy CPU being idle on jiffy boundaries) is very use dependant, occurring more on desktops than servers, and sometime more with video frame rate based tasks. Data to support my claim is a couple of years old and not very complete, but I see the issue often on trace data acquired from desktop users on bugzilla reports. Disclaimer: I fully admit that my related tests on the other thread have been rigged to exaggerate the issue.