From patchwork Thu Aug 9 17:20:02 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Leo Yan X-Patchwork-Id: 143872 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2353877ljj; Thu, 9 Aug 2018 10:20:26 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzNAN8Wg1377SLrKgMNO3BjtFpf5xLYryROHNVTCzLfzMn39LXHcgZPdV1PJxmEWCyY8vpc X-Received: by 2002:a17:902:da4:: with SMTP id 33-v6mr2792479plv.193.1533835225925; Thu, 09 Aug 2018 10:20:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533835225; cv=none; d=google.com; s=arc-20160816; b=ZBedfgPKXnUebgZRWUL7kIGKtlHjmKdmLDNCc+CCtBhLRchioMSG8QMC1JxrKNBhEw Mafg/hXqcg5m2MJk9rYhFgw+ullBBZyCWXu5eA7lQYEUgRe31hbnH65R6yARWCZQbLZA 4leuZLMZEMvepj4zpWiPvYJ3YVGFyzeroE6ozFgz2c0XLzErs95X/49HVs5vV9S+yGnX GWm2rr1yxIsE34F3iF+GQHBU2oa372A6CqcABYJt8jOfNQPin88CQnStRkwaS9sR99bj 76gn/oAt48x0PeFQB0n6JX+TlIDl7+zY0TmfNmqByEKmru+pect1SiLYbSOwk/uBbRDR QZDA== 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=QgpcAKG3c2A8jHYZwphtIY8+khQs4FPAq+KuUMISRzO8AJ3zX460ElxbgV8C3guvuo LRtJIXhw98YrktEBeOI99EBePtxqn22Rd5mTfGv3ykh4ZGXoZKNSdR/hz0vraMKG3BtL +kQUmD4hZXexbyaoQcifQB0yox0fVSisnQv1uPkCfKnuuO6lsv0EcuRwOg4WEBZIDaV+ F/hmxc+JNT/szjDjVZOMRFj9Z5sZztoVHbpUjlYaDbQxMRYNz/BcBHsdOOyIfBLk0DD0 gi8HgFcEs/2xBrmg9WWU7NHGsiD2SXPsdhk7692ds5LHy6+TN42yqMU0k/0MkxCFUxjk H8Mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TK3eGQhs; 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.25; Thu, 09 Aug 2018 10:20:25 -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=TK3eGQhs; 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 S1732598AbeHITqJ (ORCPT + 10 others); Thu, 9 Aug 2018 15:46:09 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:44558 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732368AbeHITqJ (ORCPT ); Thu, 9 Aug 2018 15:46:09 -0400 Received: by mail-wr1-f66.google.com with SMTP id r16-v6so5771558wrt.11 for ; Thu, 09 Aug 2018 10:20:19 -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=TK3eGQhsEzCwWSFTTbvyFsnlrIQLoWZkfwZFixu8e2/iKBZxnzwtwpQJzwd4RX5dgt zZ/5m7vCItz9FGqdZUIwDS/bViodUcM+Juf2vbftsbu5Y0GcrVUIHcqY8ktsYBxdrkdh 8zTTDf4K8fDQeNhCqU2W6HAOO+qnTjbMVDz6k= 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=WW4N3rqWvj/pWXimEhhxQOJnRTWDzWf4vSIBy1jlm+yL9qvsC9HHH4CsyBmDu+dDui PadlLMVBO8afhOwrBplyELWqqenjYPLqTI5neQ1kp6ktHadaWeicX7+ZCla3qGOBRrS7 yP0nVkgol/izi5RTF8y0UsK881BRXvQZRIgGliHhszEIk9RuPcCOCREVLaQK8Wr092/Z FRB9liZmb8LMlYOIAoq5mrMWELfqymphh/CKWB05NdBhLYslOlYQ3pbBUzlVHbBoQbfY weCpR+QpPzV77BAS3jaLCAY4y1rHpvvTaLxtQqhBhw6KdUJlGsOrtaPkdwt8hy7o1MUq uqhw== X-Gm-Message-State: AOUpUlH5b7G0vqIyHMno9p8PcwEUTPzDIkJCdhmMya9g7UnxId/DIb7c Ma+U6rPvYAVfmf2JVAmBcbA6Eg== X-Received: by 2002:adf:ed8e:: with SMTP id c14-v6mr1981310wro.264.1533835218448; Thu, 09 Aug 2018 10:20:18 -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.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Aug 2018 10:20:17 -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 1/2] cpuidle: menu: Correct the criteria for stopping tick Date: Fri, 10 Aug 2018 01:20:02 +0800 Message-Id: <1533835203-5789-2-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 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;