Received: by 10.213.65.68 with SMTP id h4csp1269707imn; Wed, 21 Mar 2018 06:52:43 -0700 (PDT) X-Google-Smtp-Source: AG47ELsR1Qax6hCCvqwSbNQEyCwsz5nhlFP8+CUBGu1nPupIRXHEvNlAr9bWwGpLz/31KaDto9ZK X-Received: by 10.98.87.29 with SMTP id l29mr13173751pfb.214.1521640363757; Wed, 21 Mar 2018 06:52:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521640363; cv=none; d=google.com; s=arc-20160816; b=Bl8W+IfxTXIU651BUl+sbJy8g23a2JjOXBXMrTfyd/ODwn/G34P02U+65b5QZOa6Yw Xucl8nn/BQOdcPhMm4t3AXeDuNnInoL+hleMUGajcSXGq5iTqyWFmgEHmy8+S6v2OiEk T2+tA7J3Sq+VFeE/xmbXi6xgT9+FocSrGn/cbT21A4Jo6qkD4BQdQnlha9zW3pvkTbFz H1jRyRtcIdXsaeqcUzH2c7moKDpk0g/dXtFrMmiA2HAUEalW+fTO7Luh2fth+IGiTIVK il063z+sjlfHVwdYfd4Hm+SzOn86bbBK1ojQELiUbO8kxFmQdQL4Ah6bcrfmp5+eOm3O u/mA== 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=5W3o22g/xjiD5FNYIQQY5M1bpHAHS1naKgwrBSMsyl0=; b=eaKlDVeYs4K+LvTe0NnzSLQ9Z1ro5qjil/C+DS+4aTFzrjLbo7qCjw3J626SRaYNle VYpEjkoHvVDs83/c4s3sSS5hf0hKhoLJwyrX5C2+uOcth65xzjRzd8i9VZhs5VTG+yDo eOkf/KMl7RbhXPJCXQeIaH1ZW1ZJWr1zSk+EMCv0vWsVNmHbb4CedXuOBY0Vda5J4BYV AFCBAcaye/c7Llsr8rKLk9F9Y/XiyZUQmQ1yzeongAVWmPxnOpwZVBPgTEFDT9HKe+jl 7g6E0rONznW29AX3rZ89gSXlj6RqUjVhbak2sWYoe5crDK1PZY9o/2V4OL7AQ63DaaIb ISZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@telus.net header.s=neo header.b=zKv8BiIo; 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 g9si3143511pfg.112.2018.03.21.06.52.28; Wed, 21 Mar 2018 06:52:43 -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=zKv8BiIo; 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 S1751998AbeCUNvY (ORCPT + 99 others); Wed, 21 Mar 2018 09:51:24 -0400 Received: from cmta19.telus.net ([209.171.16.92]:34106 "EHLO cmta19.telus.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751644AbeCUNvV (ORCPT ); Wed, 21 Mar 2018 09:51:21 -0400 Received: from dougxps ([173.180.45.4]) by cmsmtp with SMTP id ye94eDwaC1TXCye96enWyO; Wed, 21 Mar 2018 07:51:20 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telus.net; s=neo; t=1521640280; bh=5W3o22g/xjiD5FNYIQQY5M1bpHAHS1naKgwrBSMsyl0=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=zKv8BiIorrHYiIJ57lRNu8BDzV8j960wQHKwj0GPuUD3xzchxtZNzBSlIgdSB6Sd0 J1epcReoVYnBJKuOdthXwa49KBxUcoD/+8K65YBGpRkD6kqr9OpHtLbzwDXp0BmW31 i4rC3oD5Y2ncfPDcvVP+v9Hcwk8zPtXmdLr4PCDH6rkvxVswWGFgzzMyLM2eZlM6Yl PtyArULB2atbxA4pk7qBqC/oaR9UxkVG1xWQER/ao6upDknChpBBDrAPDb7mBRhQqO d7Im/rEBU2M4xBeqjMuU5o3MvYO/D85SrAlM7irzimsbnIZQoct2kx7N6PbmxTPmeP pcl38/4e2WdSA== X-Authority-Analysis: v=2.2 cv=TI+qcxta c=1 sm=1 tr=0 a=zJWegnE7BH9C0Gl4FFgQyA==:117 a=zJWegnE7BH9C0Gl4FFgQyA==:17 a=Pyq9K9CWowscuQLKlpiwfMBGOR0=:19 a=kj9zAlcOel0A:10 a=FGbulvE0AAAA:8 a=SoECrpf89a6sPypfcXcA:9 a=CjuIK1q_8ugA:10 a=svzTaB3SJmTkU8mK-ULk:22 From: "Doug Smythies" To: "'Rafael J. Wysocki'" Cc: "'Thomas Ilsche'" , "'Linux PM'" , "'Frederic Weisbecker'" , "'Thomas Gleixner'" , "'Paul McKenney'" , "'Rik van Riel'" , "'Aubrey Li'" , "'Mike Galbraith'" , "'LKML'" , "'Peter Zijlstra'" , "'Rafael J. Wysocki'" , "Doug Smythies" References: <2142751.3U6XgWyF8u@aspire.rjw.lan> <002d01d3c08e$f43aa750$dcaff5f0$@net> yXItejVa1FfdwyXIyey8sX In-Reply-To: yXItejVa1FfdwyXIyey8sX Subject: RE: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Date: Wed, 21 Mar 2018 06:51:13 -0700 Message-ID: <000e01d3c11b$b0ab2400$12016c00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-ca Thread-Index: AdPA3ndCPyOCgJ/ARn+Szxb5PXevmwAO2O8w X-CMAE-Envelope: MS4wfLEvB5N2sWJxbNs++zvaakAtOgN35LdDLVY9FVOsSAECQq48HKNRpsX/wDLa2hQn+pjsOvxvOYG5dx3RysWwiGNPyaSqepcTOw4Hn6r2PKqdtGDZ4Az6 sO+XEwrGn5lBQUoSfqj0/NyYYODRMDqYg0Jakvoueb3XoYb1fecd8Kw2h0CZS/rikPvZnh24O2ThVlTubL6HWZE5hR7hNLPxoLGpmzfO6mTElBAWdeub8Gen HZlg8ypDZj0tyDBhS5CUX817/XqFAE3GDbOjDzni8S40F51QSaMD7G7kl0e4Zh4yCTMnKW1q51RIiVl6PifBn8/oKKlMYXQg3SJnhkTYwxGI3c/7BGl4BTw1 uZV4kw+uRhXWSFpb1pf7YHPwR1z2ICm1h7bvaUEfkwY3YMszPy51PRg2m0GuW1FNmQh6uc2dOjEErDmo6kMOTjBeFCysunQxHpt4/gr/j3gwoS+zsrF03LY+ hSa6Ip92l0IhkjTK8lWJHhc6IrKyY9Npu0y2dFa2V9dMOOJii3LfoULKudz40YmCl5uHY9Oe3fg/DV+NhrmZwUV2S32x5CEACO69Rw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018.03.20 23:33 Rafael J. Wysocki wrote: > On Tuesday, March 20, 2018 10:03:50 PM CET Doug Smythies wrote: >> Summary: My results with kernel 4.16-rc6 and V8 of the patch set >> are completely different, and now show no clear difference >> (a longer test might reveal something). > > Does this mean that you see the "powernightmares" pattern with the v8 > again or are you referring to something else? Sorry for not being clear. I do not see any "powernightmares" at all with V8. After this e-mail I did a 3 hour trace and saw none. >> On 2018.03.20 10:16 Doug Smythies wrote: >>> On 2018.03.20 03:02 Thomas Ilsche wrote: >>> >>>...[snip]... >>> >>>> Consider the Skylake server system which has residencies in C1E of >>>> 20 us and C6 of 800 us. I use a small while(1) {usleep(300);} >>>> unsynchronized pinned to each core. While this is an artificial >>>> case, it is a very innocent one - easy to predict and regular. Between >>>> vanilla 4.16.0-rc5 and idle-loop/v6, the power consumption increases >>>> from 149.7 W to 158.1 W. On 4.16.0-rc5, the cores sleep almost >>>> entirely in C1E. With the patches applied, the cores spend ~75% of >>>> their sleep time in C6, ~25% in C1E. The average time/usage for C1E is >>>> also lower with v6 at ~350 us rather than the ~550 us in C6 (and in >>>> C1E with the baseline). Generally the new menu governor seems to chose >>>> C1E if the next timer is an enabled sched timer - which occasionally >>>> interrupts the sleep-interval into two C1E sleeps rather than one C6. >>>> >>>> Manually disabling C6, reduces power consumption back to 149.5 W. >>> >>> ...[snip]... >>> >>> Note that one of the tests that I normally do is a work/sleep >>> frequency sweep from 100 to 2100 Hz, typically at a lowish >>> workload. I didn't notice anything odd with this test: >>> >>> http://fast.smythies.com/rjw_freq_sweep.png > > Would it be possible to produce this graph with the v8 of the > patchset? Yes, sure. >>> However, your test is at 3333 Hz (well, minus overheads). >>> I did the same as you. And was surprised to confirm >>> your power findings. In my case package power goes from >>> ~8.6 watts to ~7.3 watts with idle state 4 (C6) disabled. >>> >>> I am getting different residency times than you though. >>> I also observe different overheads between idle state 4 >>> being disabled or not. i.e. my actual loop frequency >>> drops from ~2801 Hz to ~2754 Hz. >>> >>> Example residencies over the previous minute: >>> >>> Idle state 4 (C6) disabled (seconds): >>> >>> Idle state 0: 0.001119 >>> Idle state 1: 0.056638 >>> Idle state 2: 13.100550 >>> Idle state 3: 446.266744 >>> Idle state 4: 0.000000 >>> >>> Idle state 4 (C6) enabled (seconds): >>> >>> Idle state 0: 0.034502 >>> Idle state 1: 1.949595 >>> Idle state 2: 78.291793 >>> Idle state 3: 96.467974 >>> Idle state 4: 286.247524 >> >> Now, with kernel 4.16-rc6 and V8 of the patch set and the poll fix >> I am unable to measure the processor package power difference >> between idle state 0 enabled or disabled (i.e. it is in the noise). >> also the loop time changes (overhead changes) are minimal. However, >> the overall loop time has dropped to ~2730 Hz, so there seems to be >> a little more overhead in general. >> >> I increased my loop frequency to ~3316 Hz. Similar. >> >> I increased my loop frequency to ~15474 Hz. Similar. >> Compared to a stock 4.16-rc6 kernel: The loop rate dropped >> to 15,209 Hz and it (the stock kernel) used about 0.3 more >> watts (out of 10.97, or ~3% more). > > So do you prefer v6 or v8? I guess the former? Again sorry for not being clear. I was saying that V8 is great. I did more tests after the original e-mail was sent, and the noted slight overhead drop was not always there (i.e. it was inconsistent). ... Doug