From patchwork Thu Aug 9 17:20:03 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 143873 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2353893ljj; Thu, 9 Aug 2018 10:20:26 -0700 (PDT) X-Google-Smtp-Source: AA+uWPz9RU3I83r9YQsJf44Dp/J+EH2/gg1RQhnyLI3+zkfhUFcox4FohsPHROVt0Q7y5Da70dd5 X-Received: by 2002:a63:7c18:: with SMTP id x24-v6mr2991734pgc.311.1533835226573; Thu, 09 Aug 2018 10:20:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533835226; cv=none; d=google.com; s=arc-20160816; b=n/Kj+FC75WtHukNhOW/WdHY1vNh4MXO0eP4AjVD2BmduauOT9Z1fVf/xX7eMn75P2V BL/G8XZKNMnVtIw+/mcGRbOavGFyjozXZUf8mjjIuvKOi3nH4MF/zgI+iWfBS3bZwbM2 y60gf6r0oe1+8pUi6ieWS6c9SzTytTgn/CQCH3+H4R3OglNPcf4mBRNfsYyE2YBCXej6 61WKMc8Vrwg5CZ8jyg2B91NTaSNcHkRpSDdY/Yx3EXkIJ5PwWjc2ncoUz6ho+c3TBAwy x74kyFi2F+iclT6V0qrzNiWSmiaLUldyTC+XuhfuxQKNwo7DgGyZR+cu/uX8bZNP8rYC WVTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=GF32Bje0oJAW4XeP8mIAbg+OAE7k9UA39pRZeiSkJP4=; b=kvXCR159GsvQSN0Kx0sXsK1U4eKeZuG/Ro+5LsLEUCWPZqIJeNZ8D7aZng0Mlk8hQr /H2Hjv+NvkRfGy6bEQWVQ/5hXtam9xQd6Z/Ur8F8pdV20zfKU5bLBVZdqk8mWKL4uMop RCsegb26t2tXQKVa+BgNdfWXxOMKULpTtq4RS8lTYwFa6+rxJ1NuzPP7bikkfHNq66ov 62DzxHAGRERNhnrx2BM6DIRH7P0epVxosvWZx+FO6NxnSdL2VIM4cy0wf5Q06SPiLFEN p38kPuqn8HJzc6tWSjJXWoMIKPisM9/UQe9JM8NFx1Atgmp1SxsA3Cxkj7cag7PUUuge XlmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FZ+dmIhZ; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x1-v6si6734142pge.521.2018.08.09.10.20.26; Thu, 09 Aug 2018 10:20:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-pm-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 header.i=@linaro.org header.s=google header.b=FZ+dmIhZ; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732653AbeHITqN (ORCPT + 10 others); Thu, 9 Aug 2018 15:46:13 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:44564 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732576AbeHITqN (ORCPT ); Thu, 9 Aug 2018 15:46:13 -0400 Received: by mail-wr1-f68.google.com with SMTP id r16-v6so5771722wrt.11 for ; Thu, 09 Aug 2018 10:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=GF32Bje0oJAW4XeP8mIAbg+OAE7k9UA39pRZeiSkJP4=; b=FZ+dmIhZlQcz0kpao5gO2k+08QBuZGit29vjGX6HxlGHF6NDVaw9xNgIPFqqnOBnJy Q+nCBblp4OhI7XsVKbeBxeqTeSwYAhFZ1G/xgyvs3By5sluJRot66KCwebPACisx1zEZ Nke8PFj/26ee5U2I+KFbkToWebSMH8AGKSLOY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=GF32Bje0oJAW4XeP8mIAbg+OAE7k9UA39pRZeiSkJP4=; b=E5M2rGFWTXroiW92H2iAeKzApfkJa1nAqE22HtJKKNkV3ZIrz7j0SfxcOY1VXrbSXi gI4wV+2SQyBvoPXpugjNUKfcJbfaBCN+AX5cAzO0CckyqSeo/usNemx8l7lnADsdTjG2 fJfQtDM4fxUUBdzcwZRKDIUfjK0TcTIxl+0VrLPrlpBwC/7qT7aWI/vkMjiFVW0edcQD Kg9zW5AnOIKqe42ok+PJ5AcibXu5e59U4+plIZ2iC/aqLzJ6ZZpykmcJZKpuPTnL1MOH wvdIFsB7mCAuAWanvv/+UrfgJ4J+iWP9E2VgZNNGo9CnAOC1nTj81kB5RJa7MB/2WZmF f5yw== X-Gm-Message-State: AOUpUlFsryMAF4eOMiTvV4lhP6va65dX0BQcfPmIrW2yCgmh1PB01Mjc iWmvgoiDS7d9Vo1aKAPTDLNnRQ== X-Received: by 2002:adf:fdcd:: with SMTP id i13-v6mr1945680wrs.276.1533835222153; Thu, 09 Aug 2018 10:20:22 -0700 (PDT) Received: from localhost.localdomain ([45.76.138.171]) by smtp.gmail.com with ESMTPSA id u4-v6sm1815056wro.47.2018.08.09.10.20.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Aug 2018 10:20:21 -0700 (PDT) From: Leo Yan To: "Rafael J. Wysocki" , "Peter Zijlstra (Intel)" , Daniel Lezcano , Vincent Guittot , linux-kernel@vger.kernel.org, Linux PM Cc: Leo Yan Subject: [RESEND PATCH v1 2/2] cpuidle: menu: Dismiss tick impaction on correction factors Date: Fri, 10 Aug 2018 01:20:03 +0800 Message-Id: <1533835203-5789-3-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1533835203-5789-1-git-send-email-leo.yan@linaro.org> References: <1533835203-5789-1-git-send-email-leo.yan@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org If the idle duration predictor detects the tick is triggered, and with meeting the condition 'data->next_timer_us > TICK_USEC', it will give a big compensation for the 'measured' interval; this is purposed to avoid artificially small correction factor values. Unfortunately, this still cannot cover all cases of the tick impaction on correction factors, e.g. if the predicted next event is less than ITCK_USEC, then all wakening up by the ticks will be taken as usual case and reducing exit latency, as results the tick events heavily impacts the correction factors. Moreover, the coming tick sometimes is very soon, especially at the first time when the CPU becomes idle the tick expire time might be vary, so ticks can introduce big deviation on correction factors. If idle governor deliberately doesn't stop the tick timer, the tick event is coming as expected with fixed interval, so the tick event is predictable; if the tick event is coming early than other normal timer event and other possible wakeup events, we need to dismiss the tick impaction on correction factors, this can let the correction factor array is purely used for other wakeup events correctness rather than sched tick. This patch is to check if it's a tick wakeup, it takes the CPU can stay in the idle state for enough time so it gives high compensation for the measured' interval, this can avoid tick impaction on the correction factor array. Cc: Daniel Lezcano Cc: Vincent Guittot Signed-off-by: Leo Yan --- drivers/cpuidle/governors/menu.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) -- 2.7.4 diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 2ce4068..43cbde3 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -525,15 +525,13 @@ static void menu_update(struct cpuidle_driver *drv, struct cpuidle_device *dev) * assume the state was never reached and the exit latency is 0. */ - if (data->tick_wakeup && data->next_timer_us > TICK_USEC) { + if (data->tick_wakeup) { /* - * The nohz code said that there wouldn't be any events within - * the tick boundary (if the tick was stopped), but the idle - * duration predictor had a differing opinion. Since the CPU - * was woken up by a tick (that wasn't stopped after all), the - * predictor was not quite right, so assume that the CPU could - * have been idle long (but not forever) to help the idle - * duration predictor do a better job next time. + * Since the CPU was woken up by a tick (that wasn't stopped + * after all), the predictor was not quite right, so assume + * that the CPU could have been idle long (but not forever) + * to help the idle duration predictor do a better job next + * time. */ measured_us = 9 * MAX_INTERESTING / 10; } else {