Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2956302imm; Fri, 10 Aug 2018 01:00:19 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwjIusuxeO6G6Lp1XNwUpH0cC8B6Td3F6sm9TK0pIW0yqYNwBR2Bul6dkT+7Ylgz8SmlHK3 X-Received: by 2002:a63:7a43:: with SMTP id j3-v6mr5291894pgn.363.1533888019438; Fri, 10 Aug 2018 01:00:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533888019; cv=none; d=google.com; s=arc-20160816; b=E+cG+ctl8EKt/+Ev8BwCkGYHew7ZXoOB+HTSAE/nM0A9qX9bW3xW0UjwNDo5bR5XgE pefgRzTHDZxIfijuKSymsy0I2ZVmJhwV+vV6lTdYO0iYdGFfVowi2i+wqt7XX7Tj0Jmx CfcyI1pcKvniOYkLDetclJ63GEDfon8HJrFwxhDqHL/py4wBkgHsPDWwZZrXt0491QJQ 5lmIseWKT67OU311h/ZUe5zaeol0m0Iy70XNugUnWz9TZFg6uOTpBWE9j2onouU5bbIX qnfK+u+sujOZt2TJqIowcLVIsc1o7sMq7+Tb4wWXpZrVChN4GSF8XB311Ut5H+Eevbvm eXNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:arc-authentication-results; bh=GZOe1kqPME7QMfwb1Jfdp27xRVV55BTex15n4vMNoH0=; b=F7SUcA0yvb1Whh3KKpgm1Rf6iwseiUaDOb/6VCmBMlufjbxv2DPApbYcVeuZq8tXkP r5vSl78vnFIYrEyrHQBcGOCFdcIpq1WRxneJYJ3x4Bo7x9LnKjUNqpfrMQn1lhAPLvBm J+20jzkIHcCHpBrTBynKHuioyMlAlV9XhWo9hEXEb9E94E+rZR0b8Jr8Gfv6b9dRORxF Hft+Xj9w3cl+U66Ypq+/82UhWoBeQZ9nQrHxJEQLIc2yGFTlXnhRHumDnvKDqXrsA1SC vxBaaw6Jq8NcuZop10TVQAU3IjlByp4HW0EvFajeuWGpOOcrFP/6ceE+zK5/lwGna9Qd 5xhA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e9-v6si9187745pgj.70.2018.08.10.01.00.04; Fri, 10 Aug 2018 01:00:19 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727624AbeHJKFC (ORCPT + 99 others); Fri, 10 Aug 2018 06:05:02 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:59778 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727422AbeHJKFC (ORCPT ); Fri, 10 Aug 2018 06:05:02 -0400 Received: from 79.184.254.16.ipv4.supernova.orange.pl (79.184.254.16) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 4941ec66a7a73c31; Fri, 10 Aug 2018 09:36:21 +0200 From: "Rafael J. Wysocki" To: Linux PM Cc: Peter Zijlstra , LKML , Leo Yan , Frederic Weisbecker Subject: [PATCH] cpuidle: menu: Handle stopped tick more aggressively Date: Fri, 10 Aug 2018 09:34:17 +0200 Message-ID: <1951009.1jlQfyrxio@aspire.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki Commit 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped tick) missed the case when the target residencies of deep idle states of CPUs are above the tick boundary which may cause the CPU to get stuck in a shallow idle state for a long time. Say there are two CPU idle states available: one shallow, with the target residency much below the tick boundary and one deep, with the target residency significantly above the tick boundary. In that case, if the tick has been stopped already and the expected next timer event is relatively far in the future, the governor will assume the idle duration to be equal to TICK_USEC and it will select the idle state for the CPU accordingly. However, that will cause the shallow state to be selected even though it would have been more energy-efficient to select the deep one. To address this issue, modify the governor to always assume idle duration to be equal to the time till the closest timer event if the tick is not running which will cause the selected idle states to always match the known CPU wakeup time. Also make it always indicate that the tick should be stopped in that case for consistency. Fixes: 87c9fe6ee495 (cpuidle: menu: Avoid selecting shallow states with stopped tick) Reported-by: Leo Yan Signed-off-by: Rafael J. Wysocki --- drivers/cpuidle/governors/menu.c | 49 ++++++++++++++++++--------------------- 1 file changed, 23 insertions(+), 26 deletions(-) Index: linux-pm/drivers/cpuidle/governors/menu.c =================================================================== --- linux-pm.orig/drivers/cpuidle/governors/menu.c +++ linux-pm/drivers/cpuidle/governors/menu.c @@ -307,6 +307,18 @@ static int menu_select(struct cpuidle_dr /* determine the expected residency time, round up */ data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length(&delta_next)); + /* + * If the tick is already stopped, the cost of possible short idle + * duration misprediction is much higher, because the CPU may be stuck + * in a shallow idle state for a long time as a result of it. In that + * case say we might mispredict and use the known time till the closest + * timer event for the idle state selection. + */ + if (tick_nohz_tick_stopped()) { + data->predicted_us = ktime_to_us(delta_next); + goto select; + } + get_iowait_load(&nr_iowaiters, &cpu_load); data->bucket = which_bucket(data->next_timer_us, nr_iowaiters); @@ -344,29 +356,15 @@ static int menu_select(struct cpuidle_dr */ data->predicted_us = min(data->predicted_us, expected_interval); - if (tick_nohz_tick_stopped()) { - /* - * If the tick is already stopped, the cost of possible short - * idle duration misprediction is much higher, because the CPU - * may be stuck in a shallow idle state for a long time as a - * result of it. In that case say we might mispredict and try - * to force the CPU into a state for which we would have stopped - * the tick, unless a timer is going to expire really soon - * anyway. - */ - if (data->predicted_us < TICK_USEC) - data->predicted_us = min_t(unsigned int, TICK_USEC, - ktime_to_us(delta_next)); - } else { - /* - * Use the performance multiplier and the user-configurable - * latency_req to determine the maximum exit latency. - */ - interactivity_req = data->predicted_us / performance_multiplier(nr_iowaiters, cpu_load); - if (latency_req > interactivity_req) - latency_req = interactivity_req; - } + /* + * Use the performance multiplier and the user-configurable latency_req + * to determine the maximum exit latency. + */ + interactivity_req = data->predicted_us / performance_multiplier(nr_iowaiters, cpu_load); + if (latency_req > interactivity_req) + latency_req = interactivity_req; +select: expected_interval = data->predicted_us; /* * Find the idle state with the lowest power while satisfying @@ -403,14 +401,13 @@ static int menu_select(struct cpuidle_dr * 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. */ - if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) || - expected_interval < TICK_USEC) { + if (((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) || + expected_interval < TICK_USEC) && !tick_nohz_tick_stopped()) { unsigned int delta_next_us = ktime_to_us(delta_next); *stop_tick = false; - if (!tick_nohz_tick_stopped() && idx > 0 && - drv->states[idx].target_residency > delta_next_us) { + if (idx > 0 && drv->states[idx].target_residency > delta_next_us) { /* * The tick is not going to be stopped and the target * residency of the state to be returned is not within