From patchwork Tue Dec 16 06:52:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Len Brown X-Patchwork-Id: 5499581 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 910F5BEEA8 for ; Tue, 16 Dec 2014 06:52:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6ED7A20A14 for ; Tue, 16 Dec 2014 06:52:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D099920A24 for ; Tue, 16 Dec 2014 06:52:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751113AbaLPGwV (ORCPT ); Tue, 16 Dec 2014 01:52:21 -0500 Received: from mail-yh0-f43.google.com ([209.85.213.43]:36595 "EHLO mail-yh0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750983AbaLPGwS (ORCPT ); Tue, 16 Dec 2014 01:52:18 -0500 Received: by mail-yh0-f43.google.com with SMTP id z6so5867864yhz.16 for ; Mon, 15 Dec 2014 22:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references:reply-to:organization; bh=1DkZ0+m44Lunk5h6gr0aX7e2m4apXhjNFRUbdq29wxQ=; b=IzxWt5tQXgCj/k/OB22t6yWR5RYStk+olt5l70+YGlgdGEAiTV6t2RQFsIgtY7AJQ5 6R86+rA18TfD+CAlDHWSNudy9jeEWbMlzWKy2Uus0L7HOpT6DBjCx6DIs0Mj05XQCg8L HUTaSfmPfKVYMuTNNHJW3aurGnxQ4pKtImNBYsXgiKTekEX6hyz++9uSM2jDbSMAdGKI WvnG2K+o49sPmTqEWGdcjjcuV7YZdV3CetyRPxzgn2Lbnlu5LOo7LK+BTGSUe2KQP2Qt 49S85mSt1I+clnRIuoVkaaqu8Sc2VJTNVlPq+2ENRrNUZXHZk2KHcMb9bmBfX9DNqi4b ZU4A== X-Received: by 10.236.30.197 with SMTP id k45mr25205309yha.163.1418712737602; Mon, 15 Dec 2014 22:52:17 -0800 (PST) Received: from localhost.localdomain (pool-108-20-130-222.bstnma.fios.verizon.net. [108.20.130.222]) by mx.google.com with ESMTPSA id v68sm7336009yhp.2.2014.12.15.22.52.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Dec 2014 22:52:17 -0800 (PST) From: Len Brown To: linux-pm@vger.kernel.org, linux-acpi@vger.kernel.org Cc: Len Brown , Daniel Lezcano Subject: [PATCH 2/3] cpuidle ladder: Better idle duration measurement without using CPUIDLE_FLAG_TIME_INVALID Date: Tue, 16 Dec 2014 01:52:07 -0500 Message-Id: <83e27d4a9f387aa9781de927ea7f436f388de7bd.1418712225.git.len.brown@intel.com> X-Mailer: git-send-email 2.1.2.451.g98349e5 In-Reply-To: <1418712728-2193-1-git-send-email-lenb@kernel.org> References: <1418712728-2193-1-git-send-email-lenb@kernel.org> In-Reply-To: References: Reply-To: Len Brown Organization: Intel Open Source Technology Center Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Len Brown When the ladder governor sees the CPUIDLE_FLAG_TIME_INVALID flag, it unconditionally causes a state promotion by setting last_residency to a number higher than the state's promotion_time: last_residency = last_state->threshold.promotion_time + 1 It does this for fear that cpuidle_get_last_residency() will be in-accurate, because cpuidle_enter_state() invoked a state with CPUIDLE_FLAG_TIME_INVALID. But the only state with CPUIDLE_FLAG_TIME_INVALID is acpi_safe_halt(), which may return well after its actual idle duration because it enables interrupts, so cpuidle_enter_state() also measures interrupt service time. So what? In ladder, a huge invalid last_residency has exactly the same effect as the current code -- it unconditionally causes a state promotion. In the case where the idle residency plus measured interrupt handling time is less than the state's demotion_time -- we should use that timestamp to give ladder a chance to demote, rather than unconditionally promoting. This can be done by simply ignoring the CPUIDLE_FLAG_TIME_INVALID, and using the "invalid" time, as it is either equal to what we are doing today, or better. Signed-off-by: Len Brown Cc: Daniel Lezcano Acked-by: Daniel Lezcano --- drivers/cpuidle/governors/ladder.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/cpuidle/governors/ladder.c b/drivers/cpuidle/governors/ladder.c index 37263d9..401c010 100644 --- a/drivers/cpuidle/governors/ladder.c +++ b/drivers/cpuidle/governors/ladder.c @@ -79,12 +79,7 @@ static int ladder_select_state(struct cpuidle_driver *drv, last_state = &ldev->states[last_idx]; - if (!(drv->states[last_idx].flags & CPUIDLE_FLAG_TIME_INVALID)) { - last_residency = cpuidle_get_last_residency(dev) - \ - drv->states[last_idx].exit_latency; - } - else - last_residency = last_state->threshold.promotion_time + 1; + last_residency = cpuidle_get_last_residency(dev) - drv->states[last_idx].exit_latency; /* consider promotion */ if (last_idx < drv->state_count - 1 &&