Received: by 10.213.65.68 with SMTP id h4csp796122imn; Thu, 22 Mar 2018 08:44:51 -0700 (PDT) X-Google-Smtp-Source: AG47ELtG4qPZicvshvZMMtimQR3777lvvGFJIAA9a8fMnR0Jp9VrEJbd2SOAiLjdVvNMwC8Ki1gz X-Received: by 2002:a17:902:2468:: with SMTP id m37-v6mr24998353plg.388.1521733491368; Thu, 22 Mar 2018 08:44:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521733491; cv=none; d=google.com; s=arc-20160816; b=SGVUEXQfTLCelhrcgT03KqHIcHcz38HGx3Os/1vZyuhXfAu9YAC4LrhFr6hgQwh/bO WCN0cCCz1dGnrv0MFw+ywn5BYuj8LHmWvTdWvRvSeToqYl12Sk37eiJPR1nr6nv/OVTe RVnWY8gvVWtl7QgnOAivoYMnfTdo4AeDmWN0Jn+WiY7ddMDPEuGxNaZprNvebGjKXF3O WyaEI7DRI+8Fe70eJNnlJWFiKp/t2Jwqg4YtiMgB1y/43u1x0ZCscw+ZyLmAYvDXeqDd V5CdaUW6trIh5PewF3IohtCGDNMRG74UJMXrr7I2I1uB2WkDkRuO6AfgY8LxULOibdmA 45fA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:content-language :content-transfer-encoding:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:dkim-signature :arc-authentication-results; bh=QOoWvNfvrCXQk62DKvhkJ4PeXfTKFITtfhscYuTc11c=; b=anzyiu/feYzPch8vk6Cp1HIW2R+9WhiklkWWVQxLadjENhyh3z1xdLcLAxjqEWfl9D +5ecy71hsCr+I7B02ettMQNjtcIOB9q/In8+aMuzyBzO6H/asVBZHmuSIqrbxd1Bdtyv S3nBFBMcIkpRhugaut400qXhwRuYB8kWDtgCctM7cwEw0uIDuc2+FKkhVCq6dua6ENQi Wqjy8ps0H+juID/ydNeY/wQwdAG+yVyrScB0N1yPOzuLf53g3EEImKPiMLaIMCrTFrj6 s3IrB90fO7O7SZ4mvIotdUUie2jYQC1tiXxnhb232xFDqm6NH0pnYOjJyj/4a6QEME4m tVwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@telus.net header.s=neo header.b=n00dx1Fq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telus.net Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e67si4534124pgc.274.2018.03.22.08.44.36; Thu, 22 Mar 2018 08:44:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@telus.net header.s=neo header.b=n00dx1Fq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=telus.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751761AbeCVPmF (ORCPT + 99 others); Thu, 22 Mar 2018 11:42:05 -0400 Received: from cmta18.telus.net ([209.171.16.91]:49088 "EHLO cmta18.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbeCVPmA (ORCPT ); Thu, 22 Mar 2018 11:42:00 -0400 Received: from dougxps ([173.180.45.4]) by cmsmtp with SMTP id z2LjeRnFricTMz2LkeHwPr; Thu, 22 Mar 2018 09:41:59 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=neo; t=1521733319; bh=QOoWvNfvrCXQk62DKvhkJ4PeXfTKFITtfhscYuTc11c=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=n00dx1FqVVqqTiITzpyli372XyFEpKJE7eoeYhM6YEUDilBEkUvttKbGPLh/qlldv zAfrUUXHzVM4DMiljjlZjrGykx1ANFgBsQL8kpawnx1Ktbhwi4S/xiTxwGrBSyJm/7 WD73q1a/piC59iIzH3Hg1OFK3FuNzFlwpxU8RxHk377K75q3qgxUdxHElwWKoaLOGd JgvQTXBah3t+fZEKI+h0omHeh4KxIy5BYel8a1g1pNaNLjjXilE2PY8rDes/3v572u HbeJi4csn8IoZERFDrcCr9L3otF/FHxQe6zlDEMWBN8J1JI4Op8qznl+sUYfEDz7EK npaZVJkejEn5Q== X-Authority-Analysis: v=2.2 cv=ebrSR/MH c=1 sm=1 tr=0 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=IkcTkHD0fZMA:10 a=VwQbUJbxAAAA:8 a=HLEhOUT7AAAA:8 a=FGbulvE0AAAA:8 a=6zee2FuY2o9LUhDUDAwA:9 a=QEXdDO2ut3YA:10 a=AjGcO6oz07-iQ99wixmX:22 a=73WewclNby-GrhdgABwy:22 a=svzTaB3SJmTkU8mK-ULk:22 From: "Doug Smythies" To: "'Rafael J. Wysocki'" , "'Thomas Ilsche'" Cc: "'Linux PM'" , "'Peter Zijlstra'" , "'Frederic Weisbecker'" , "'Thomas Gleixner'" , "'Paul McKenney'" , "'Rik van Riel'" , "'Aubrey Li'" , "'Mike Galbraith'" , "'LKML'" , "Doug Smythies" References: <2390019.oHdSGtR3EE@aspire.rjw.lan> <1635957.yuHkCe9oyz@aspire.rjw.lan> ym0ceyYVT1Konym0eegfln ysl4eqMKwFfdwytebe4RNZ In-Reply-To: ysl4eqMKwFfdwytebe4RNZ Subject: RE: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select() Date: Thu, 22 Mar 2018 08:41:54 -0700 Message-ID: <000401d3c1f4$5043adb0$f0cb0910$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-ca Thread-Index: AdPBYg/Oh/zHpvmbQaGiHmKF6GMzzgAO92wgABPNHDA= X-CMAE-Envelope: MS4wfEQqqI6vvfONZC8wPnA1BnalzRImpZKyhKRIvXJbIGiIFa8hC6z/RSZai+t74qFDJhDDOc6E0S6OjFnK6uGwga+8S1fyD+XzANqn8aErsXiqZ6pM39ke I6jxrxx1av2/rZu/N+qAU2eKUUZTCQ2HRnHEiLANEZlUguXcFO7useFLrdY7O87IMU827u7Wp/+4M2F2YUb58B/EvaY3t/usUr0XX/52r4QF8cvBhll8/nhP zhY76g1FP82ULypxx/Sfm/AbXRg/7wXJzXydvru+kPGB8vaxRewcnhg4EvNDSveqsFNcJf15eDXjbOUtioLSlhdItnAiPhy/jfnyGMVlzLAXrL1kq49t4+wJ NqO57Ze3b11dRazOdaOy5ASwBcbV0+ntHu/Y/GbasPUAN5Yw7YCA7/9R/ufYG/cbzzbwsPx1rSbx0Fmb8o25wjsvc58Wf/WY+GGVM8kfeNY2ZkiP6FJ2b1ci Hp2uRNDVAaYamy3iCggfm998Unnmr/UN0nq1LfVPqy9L0UIz8JYN4x+SwFc= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018.03.21 23:25 Doug Smythies wrote: > On 2018.03.21 15:15 Rafael J. Wysocki wrote: >> On Wed, Mar 21, 2018 at 6:59 PM, Thomas Ilsche wrote: >>> On 2018-03-21 15:36, Rafael J. Wysocki wrote: >>>> >>>> So please disregard this one entirely and take the v7.2 replacement >>>> instead of it:https://patchwork.kernel.org/patch/10299429/ >>>> >>>> The current versions (including the above) is in the git branch at >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ >>>> idle-loop-v7.2 >>> >>> With v7.2 (tested on SKL-SP from git) I see similar behavior in idle >>> as with v5: several cores which just keep the sched tick enabled. >>> Worse yet, some go only in C1 (not even C1E!?) despite sleeping the >>> full sched tick. >>> The resulting power consumption is ~105 W instead of ~ 70 W. >>> >>> https://wwwpub.zih.tu-dresden.de/~tilsche/powernightmares/v7_2_skl_sp_idle.png >>> >>> I have briefly ran v7 and I believe it was also affected. I am not seeing any issues at all with V7. >> >> Then it looks like menu_select() stubbornly thinks that the idle >> duration will be within the tick boundary on those cores. >> >> That may be because the bumping up of the correction factor in >> menu_reflect() is too conservative or it may be necessary to do >> something radical to measured_us in menu_update() in case of a tick >> wakeup combined with a large next_timer_us value. >> >> For starters, please see if the attached patch (on top of the >> idle-loop-v7.2 git branch) changes this behavior in any way. > > O.K. I am seeing some weirdness. > On my system with both V7.2 and V7.2 plus this patch, I observe > A spike in Idle State 1 residency every 34+ minutes. And slightly > higher average idle power than before. > (I might not have done V7 idle tests long enough). I re-did the idle test on V7, and for longer. It is great. See line added to the idle graph for V7.2+: http://fast.smythies.com/rjw_v72p_v7_idle.png > > It can be seen in the frequency sweep I did earlier today, with V7.2: > > http://fast.smythies.com/rjw_freq_sweep_72_combined.png > > Despite the note on the graph that says it might be real, I don't think > it is (I forgot to delete the note). > > With V7.2+ sometimes the event occurs at 17 minute intervals. > Here is a idle graph (for reference: we have seen idle package power > pretty steady at ~3.7 watts before). Now shown on the new graph. Link above. > > http://fast.smythies.com/rjw_v72p_idle.png ... Doug