From patchwork Wed Mar 21 22:15:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Rafael J. Wysocki" X-Patchwork-Id: 10300463 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 92C0A60385 for ; Wed, 21 Mar 2018 22:17:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7DA2220499 for ; Wed, 21 Mar 2018 22:17:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6FCEA2267B; Wed, 21 Mar 2018 22:17:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F0DA429622 for ; Wed, 21 Mar 2018 22:15:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753979AbeCUWPH (ORCPT ); Wed, 21 Mar 2018 18:15:07 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:38844 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753826AbeCUWPD (ORCPT ); Wed, 21 Mar 2018 18:15:03 -0400 Received: by mail-ot0-f193.google.com with SMTP id 95-v6so7351173ote.5; Wed, 21 Mar 2018 15:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7CX02sR7sSgr6+iLPth8CY9sHUOdL4uLsMYQXpyMn8Q=; b=EDIRR97QqizEA1Y6w0h1SyGsq7OA4r6KQcqfnakFzYpHcgeCJn8fxpQHzaMzaEZCOp JiHJbSx09V9U7pgXoTpl5qFfBO0bhcdDoW4zTeXqAiTzEBis7Y83WoM/yDdnL71jxI/u kuHeln5jO0c34FLT7rEL6We5poftry7y0oxsxWDvyfsWfo40ITKTOXGkjINgnegqLwWS sIMfYcsOqBNaAG/o/ovxPtNKBrmxubc8e7x95NQtoG1VZGLiYJAgHCc+8mW9J7U/n/rS ih115YgvIbkQ93xC92m88TVf7O2wGOgNSRhJFHPKB3zpvIO49LcMWngTW6YX7rHUvUQE 3uBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7CX02sR7sSgr6+iLPth8CY9sHUOdL4uLsMYQXpyMn8Q=; b=fnFTFM8c5HuPbbDeTNLtenwGU8mtWQyTbWL/3xNfPTEo+XfX7ykbL1bYQV8QL73OZE 680Rf/KwtHdRyBsjLLsz0JIPZGy9EIeUpRlkTYMDkAPoYDCjTlwAklCd/kd+kQQpJhyj JfwEB6G8WF3l1OIDWS0rl4Vt32QIPbjWobv1/i/GfTIjOokCmebRTDpmD2ht70vxqLhE Q/m2l52kY60YV8DJT5qEc47m0WnXa+k4ARdjJBzMHEwQiPPKBUcm0qS+qOL99i9lNC7O f4Hc+/+EDElEOlzdi3WFDypc/FAP3POyci9mDSveR3HEL8otxWvgAUX3RUvgEZ+ZI1Cc aBJg== X-Gm-Message-State: AElRT7FoCyZCFBRcSnnnV6sC6xV7hnaCTHpJIqQaX4ffHkCinh3GCyqL wIczC6V9m7G6ATXUFKTPzg8c4aCMSwufxLJ3ia0= X-Google-Smtp-Source: AG47ELv6YtQO9W2K8sRo6C5Dr5by7M1fOn4ixRUhHiwLf/aXdhk/rib+yQM1R1I/Clo3JFaucV+Hq79SgTwCc1hGR9I= X-Received: by 2002:a9d:5b44:: with SMTP id e4-v6mr12673438otj.305.1521670502667; Wed, 21 Mar 2018 15:15:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:9f7:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 15:15:01 -0700 (PDT) In-Reply-To: References: <2390019.oHdSGtR3EE@aspire.rjw.lan> <1635957.yuHkCe9oyz@aspire.rjw.lan> From: "Rafael J. Wysocki" Date: Wed, 21 Mar 2018 23:15:01 +0100 X-Google-Sender-Auth: SThFWxlApilA4ju_xd7Wh0w7XuY Message-ID: Subject: Re: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select() To: Thomas Ilsche Cc: "Rafael J. Wysocki" , Linux PM , Peter Zijlstra , Frederic Weisbecker , Thomas Gleixner , Paul McKenney , Doug Smythies , Rik van Riel , Aubrey Li , Mike Galbraith , LKML Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. 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. --- drivers/cpuidle/governors/menu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/drivers/cpuidle/governors/menu.c =================================================================== --- linux-pm.orig/drivers/cpuidle/governors/menu.c +++ linux-pm/drivers/cpuidle/governors/menu.c @@ -498,7 +498,7 @@ static void menu_reflect(struct cpuidle_ * correction factor. Use 0.75 * RESOLUTION (which is easy * enough to get) that should work fine on the average. */ - new_factor += RESOLUTION / 2 + RESOLUTION / 4; + new_factor += RESOLUTION; data->correction_factor[data->bucket] = new_factor; } else { data->needs_update = 1;