From patchwork Tue Aug 7 14:27: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: 143585 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp4576898ljj; Tue, 7 Aug 2018 07:27:39 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdmhncNxGl/qN2fEQc45BPB2R/YDicEy0e2p/zSt0AkfGeSMmb5uet42mKTDEivE3Hg2WZb X-Received: by 2002:a65:630e:: with SMTP id g14-v6mr19160620pgv.153.1533652058848; Tue, 07 Aug 2018 07:27:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533652058; cv=none; d=google.com; s=arc-20160816; b=PKzpGA8KhkQGVQrkZ8Cn2PdWZXnqAUry/GiygG1FJUuHK685GaQHvYuGe4/NwxLND9 KozhJs+p5pomx3mf84LtBca8gVPwpriZMp6OYGFi3DW/jnBdrxaGJAeF3Kh0Zx3VgFgR lFcbB0vXNspXLX7Uk3nLCNVYUevWaeazJ1lclGV8jG+kjjp9+lznGFdvBXkxWMY14lsd 63GIEZt6JzaXVD7Jq8gcMENBOGIAyDJsbLwoEyN52c0TqnZP6hTx0/Ugr9VvVd0QsJIu 2EuST0y6BX3wduZDjzDeBn/qMANkwRKBrbKgiiZ+76AcncVgK0Z9bW99HmTeB6HpG2CH OvAA== 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=tQeOn7z2zgtAWzzjccDSf6WarhVnTGNmsaV0jykRFsI=; b=VhdSV4C98OJ/hYnkuhK3QUvtQDf8Bf6F57Eft4J7x0HOblvArR7TEMSsRlLkX+7iiH uP+U7xD6c43NDkI1EhW83ovgAN85iO06PsnMxqGzYC8BD7ib50fQkDMfgawXwbMmWmbZ mWBAqwzyODKyqF+9x8Hp5qw/l8s/71T+3kvkdQkdOktGckNeAg+nRGsoFU46SPxYdB0i c/p6XWpFedHoK1LFv4Ur261/yhSD+ciiDg+39/j+CLSTDXGdYCMjUfJE7YP1Q+7FBlfb AWaGgwvZClO34KLsw958v6un1j2wdZhN6JZi0eIHDVNf2dmZ/eokg4msGNQZuQHMdV71 8JRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FFyWBkO4; 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 b25-v6si1286096pgf.545.2018.08.07.07.27.38; Tue, 07 Aug 2018 07:27:38 -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=FFyWBkO4; 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 S2389585AbeHGQmL (ORCPT + 31 others); Tue, 7 Aug 2018 12:42:11 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:43841 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732639AbeHGQmL (ORCPT ); Tue, 7 Aug 2018 12:42:11 -0400 Received: by mail-wr1-f67.google.com with SMTP id b15-v6so15961035wrv.10 for ; Tue, 07 Aug 2018 07:27:35 -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=tQeOn7z2zgtAWzzjccDSf6WarhVnTGNmsaV0jykRFsI=; b=FFyWBkO4mnuuNLywipWC8gaY1wDIF6KFi8+g60KsIXFLf6aA3WgSdIBNIWdXrlZcFq IYThJczA0SONEWaiWLAjQUKYyyJtux0WpQZCOsH7ciohXTdIgQ2ToPtcN6RwnWcuDzvy bUbWJ3duihUwKsVsaQft8BeZobd5XjSw+UiT8= 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=tQeOn7z2zgtAWzzjccDSf6WarhVnTGNmsaV0jykRFsI=; b=paxVxf6ZImFCQSwChVUijM9JCROdbbsTDwC8aQ193t5LIED5uTi4AE3vKvJyMnnEAj s65uwwGSw6W8ZLXUWWQUTTLN+9TURZl8IFyFyuQ1FU+rlJCflgLf0ZKTDIc5FJpDT1J/ 4t1CZi0lNTR55spNfDPomaipWHtUjNfITtqhAO/X79BzcLjQwKzi2gHmwVyL10qKs1gg gTnADEIXn6DgAvfmoPogQsNP4iS1KKG/G9sfzdfyuBSFd+HCZVvqGbD860fgCnT+pLQc gPRHn4+jsa4KScN0wtbeiS6WmtYcQqUFuD+TEJSbv5Q6HBf2gbUZs9zJzZHUP3GuwV4w S3eg== X-Gm-Message-State: AOUpUlH0Fu9Xk9t+E21e6qxjGdviZvi0H1C0ObkN7QFfFRXGh0Y8oSMD n0c8nPEEDwEi2Q+pFG9FFyC6Mw== X-Received: by 2002:adf:ed8e:: with SMTP id c14-v6mr12617063wro.264.1533652054795; Tue, 07 Aug 2018 07:27:34 -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.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Aug 2018 07:27:34 -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 1/2] cpuidle: menu: Correct the criteria for stopping tick Date: Tue, 7 Aug 2018 22:27:03 +0800 Message-Id: <1533652024-19078-2-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 The criteria for keeping tick running is the prediction duration is less than TICK_USEC, the mainline kernel configures HZ=250 so TICK_USEC equals to 4000us, so any prediction is less than 4000us will not stop tick and the idle state will be fixed up to one shallow state. On the other hand, let's use 96boards Hikey (CA53 octa-CPUs) as an example, the platform has the deepest C-state is cluster off state which its 'target_residency' is 2700us, if the 'menu' governor predicts the next idle duration is any value fallen into the range [2700us, 4000us), then the 'menu' governor will keep sched tick running and and roll back to a shallow CPU off state rather than cluster off state. Finally we can see the CPU has much less chance to run into deepest state when a task repeatedly running on it with 5000us period and 40% duty cycle (so the task runs for 2000us and then sleep for 3000us in every period). In theory, we should permit the CPU to stay in cluster off state due the CPU sleeping time 3000us is over its 'target_residency' 2700us. This issue is caused by the 'menu' governor's criteria for decision if need to enable tick and roll back to shallow state, the criteria is: 'expected_interval < TICK_USEC'. This criteria is only considering from tick aspect, but it doesn't consider idle state residency so misses better choice for deeper idle state; e.g., the deepest idle state 'target_residency' is less than TICK_USEC, which is quite common on Arm platforms. To fix this issue, this patch is to add one extra variable 'stop_tick_point' to help decision if need to stop tick or not. If prediction is longer than 'stop_tick_point' then we can stop tick, otherwise it will keep tick running. For 'stop_tick_point', except we need to compare prediction period with TICK_USEC, we also need consider from the perspective of deepest idle state 'target_residency'. Finally, 'stop_tick_point' is coming from the minimum value within the deepest idle state 'target_residency' and TICK_USEC. Cc: Daniel Lezcano Cc: Vincent Guittot Signed-off-by: Leo Yan --- drivers/cpuidle/governors/menu.c | 41 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 2 deletions(-) -- 2.7.4 diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 30ab759..2ce4068 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -294,6 +294,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev, unsigned int expected_interval; unsigned long nr_iowaiters, cpu_load; ktime_t delta_next; + unsigned int stop_tick_point; if (data->needs_update) { menu_update(drv, dev); @@ -406,11 +407,47 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev, idx = 0; /* No states enabled. Must use 0. */ /* + * Decide the time point for tick stopping, if the prediction is before + * this time point it's better to keep the tick enabled and after the + * time point it means the CPU can stay in idle state for enough long + * time so should stop the tick. This point needs to consider two + * factors: the first one is tick period and the another factor is the + * maximum target residency. + * + * We can divide into below cases: + * + * The first case is the prediction is shorter than the maximum target + * residency and also shorter than tick period, this means the + * prediction isn't to use deepest idle state and it's suppose the CPU + * will be waken up within tick period, for this case we should keep + * the tick to be enabled; + * + * The second case is the prediction is shorter than the maximum target + * residency and longer than tick period, for this case the idle state + * selection has already based on the prediction for shallow state and + * we will expect some events can arrive later than tick to wake up the + * CPU; another thinking for this case is the CPU is likely to stay in + * the expected idle state for long while (which should be longer than + * tick period), so it's reasonable to stop the tick. + * + * The third case is the prediction is longer than the maximum target + * residency, but weather it's longer or shorter than tick period; for + * this case we have selected the deepest idle state so it's pointless + * to enable tick to wake up CPU from deepest state. + * + * To summary upper cases, we use the value of min(TICK_USEC, + * maximum_target_residency) as the critical point to decide if need to + * stop tick. + */ + stop_tick_point = min_t(unsigned int, TICK_USEC, + drv->states[drv->state_count-1].target_residency); + + /* * Don't stop the tick if the selected state is a polling one or if the - * expected idle duration is shorter than the tick period length. + * expected idle duration is shorter than the estimated stop tick point. */ if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) || - expected_interval < TICK_USEC) { + expected_interval < stop_tick_point) { unsigned int delta_next_us = ktime_to_us(delta_next); *stop_tick = false; 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 {