From patchwork Tue Aug 7 14:27:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 143586 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp4576962ljj; Tue, 7 Aug 2018 07:27:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcbWgRKp/+Ydy9fy7RO6sH9ZPZCR3XEt7rZSl4Kv7/5ZhYZHGbRNVdkzgSX+sgRWwN5g26/ X-Received: by 2002:a63:383:: with SMTP id 125-v6mr19168376pgd.421.1533652063134; Tue, 07 Aug 2018 07:27:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533652063; cv=none; d=google.com; s=arc-20160816; b=xGU4jMIGUi1fo3KH68JUUcXvt2TrbqIA7gV8OH5A9DN6q7z7yYPWePtzvgpN5/bQI/ Qja17a8+gZ8yjDS2icHCn8QVL0i5xUwg6YF0WXxaUtLXBWJ+cTdNP2IaiVPeNbIykQSJ cj0SUgeStGy/Pm7myPKqlgnQjIsS8ozwTlSL5qOqX6xJP1isJIAw9NB1WuvLLHCu7Nhd JrN6EQna41sBrHJUQY0tD+wXMHNHvT8TBBqk6PJMlWj71sdEk7I960MFTxkIh+mTCfGg 22URP58Kky8T7Em9P4gCZQ05hlkuPB9VSPBbEjhF5uAG9g4/ipssrndf0Qp5nAhw2QO9 /7RQ== 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=Z4Poc/+ydrmZ5wJ7FKohboOJ6NotFB6Ax/vrCTuLxS8t2n34DjEKuA5dgsh/+Uus// j2E3NirKDCb6xBqa2MBgsI+EiQ3Pp7KaKb0tvZp2/NcQNCZ1h+QR7GhN3yVZPGvSR4co 1A9PijUuLwIhrRexSPt2549CKeuSNeiOKlY3BRIdmTqKCwIyRrlZr7cPA4Jw6y0hcpMh 06sSGO3uU5DiY7vzVlOw3QOx20qQId+pRjIdk6FNM+VjZUgIVZlZlUdlJwMu3SmizGD5 XXRkM4P/PdnHUM0pKn97a7b3aBO0g3qy+ce2gO8j2Hzf4mXsoJYH6GBQBltb49MwBTZw RNjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aX0AT3kG; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u186-v6si1536406pfu.263.2018.08.07.07.27.42; Tue, 07 Aug 2018 07:27: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 header.i=@linaro.org header.s=google header.b=aX0AT3kG; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389599AbeHGQmP (ORCPT + 31 others); Tue, 7 Aug 2018 12:42:15 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:39653 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389073AbeHGQmP (ORCPT ); Tue, 7 Aug 2018 12:42:15 -0400 Received: by mail-wr1-f65.google.com with SMTP id h10-v6so15974788wre.6 for ; Tue, 07 Aug 2018 07:27:39 -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=aX0AT3kGNzJQz68KD5g0XdNbHR9IF93ol2MzrLU9f2azNlqBmztQ3iAMwf00ZzDI4D whxX8tF35vHTiiaObpE0/aKhPu+Mk1NV/6cpToUUfpdHcmpKhq4VYHQSSOZuTwnnpWee KIYGdQSO5KwXYDMPSroFYnBrwsXJsZ2F3lIlw= 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=NaGUyZOVmCGJ1z/N+jBKsi0fmDBCKjViK+ub8WHRZya4jX8j5ia9WIZ7/0qOci3Z4d soDhkYkup7e9acRqwXeJAIPJh2Lc2YL+jNbrJIw9jY267u5IFiD4udyUrhd/Wjd+YUv3 krT7bM0eyWRJzewDlc+Nthb6F1zaGWKiYJEhamMJCapSy7CUbkVzo+QkkzyIcQeSC9WP 9YZR66lV7o0umv/unaT6bRdgBofdC9lb6ExPw69i8jO2wGtyg65MnGAEeqQV9PRMFRcD WjYXnJOXart2vv2nqOXvGf1pliBddCpAdW+zw3XtVYoJ1/MP7FmqDqLE59q8NU+nJwtB /SUQ== X-Gm-Message-State: AOUpUlEQ+vGsrIZQC06S+XCWdOzwmMgdVVRVqVst7DyFno4R4/I8sgwg 8bi5LDzAlY3BtUleLBZEY8D9NQ== X-Received: by 2002:a5d:434c:: with SMTP id u12-v6mr11890243wrr.189.1533652059331; Tue, 07 Aug 2018 07:27:39 -0700 (PDT) Received: from localhost.localdomain ([45.76.138.171]) by smtp.gmail.com with ESMTPSA id t13-v6sm1478787wrr.74.2018.08.07.07.27.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Aug 2018 07:27:38 -0700 (PDT) From: Leo Yan To: "Rafael J. Wysocki" , "Peter Zijlstra (Intel)" , Ramesh Thomas , Daniel Lezcano , Vincent Guittot , linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v1 2/2] cpuidle: menu: Dismiss tick impaction on correction factors Date: Tue, 7 Aug 2018 22:27:04 +0800 Message-Id: <1533652024-19078-3-git-send-email-leo.yan@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1533652024-19078-1-git-send-email-leo.yan@linaro.org> References: <1533652024-19078-1-git-send-email-leo.yan@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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 {