Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9022042ybi; Wed, 10 Jul 2019 03:24:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqxew6GHiWCWwpNkkedsXxscG5IS1gQ8/yl7rdlRjrWIYeALFwY5JcPuHr9MkCFF5ld9BqPT X-Received: by 2002:a17:90a:2041:: with SMTP id n59mr5923922pjc.6.1562754244534; Wed, 10 Jul 2019 03:24:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562754244; cv=none; d=google.com; s=arc-20160816; b=VqHfhA7MQUbTDhfHdWJ4s47fuiXhpywv0Xhz0qYdNjWnJ8TzaU0V5acgVZdyKO0FNk fbJMc9UlSA5ZKJ/Z4PLmDGXtCoGxg+lunIAReReZ+T0dCuQugZiOQqLFuHnFP3sYtnUs c+bYCy8Edf+se4YaB6NkhmOiwQpssybDRt/s+5wv1ckMwRzSaUSYWv+WVobeAHBVVy/Z 66QiSkqfJwCPqb7Spts3ACRQa2fLK2fXKgL7COGv/7TrGuyMYLsU7RL5hzcStnL2yX01 0uNRAts2OKGFrzr6nDNO6Ok4OiQmizA+wFxnr2xVJ1q5MIkSHsAQVu9pSz5976UTC8ab qttA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=r2sCZ6HW9AJoZl0xRFREr7DdMfptAWj7Xr4WXWFrCWc=; b=IeoLVojjWnpAC58w7ZT/6cLV5z2yTjoFIzkRxL6Rhkb4ll+5TzlHC95mGUKZqwBa3B 0GB+UO+cNYsYp8WSfiWnAWnsR2PGRH0G2XretXQgF7yLtH4gyVU8OBltSc+vt6WMXvCB xs3Z7qGt929jt25JWQyd6jMoe1o3NaJBVVgiucb2yWcNYOCxcnB+SF9iVtt/57xQbuno TVvXDi5gP7oUg5FIvvHoqqQ6IsVL4DaAz72fYjyQbvQ9niiWMoUDcALVizndLWGlSzrD SVv7W4Iho+kjHxUGjqPAinSGDlY8JDyoH3Ni51J4zjYz7SoFLm6cHp+ZS+1JeGPZuLT9 9W5g== 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 e1si1745021plt.276.2019.07.10.03.23.48; Wed, 10 Jul 2019 03:24:04 -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 S1727295AbfGJKWq (ORCPT + 99 others); Wed, 10 Jul 2019 06:22:46 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:59446 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbfGJKWq (ORCPT ); Wed, 10 Jul 2019 06:22:46 -0400 Received: from 79.184.253.121.ipv4.supernova.orange.pl (79.184.253.121) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.267) id 7b98129f9fda85dd; Wed, 10 Jul 2019 12:22:43 +0200 From: "Rafael J. Wysocki" To: Thomas Lindroth Cc: Linux PM , Linux Kernel Mailing List , Peter Zijlstra , Frederic Weisbecker Subject: Re: The tick is active on idle adaptive-tick CPUs when /dev/cpu_dma_latency is used Date: Wed, 10 Jul 2019 12:22:43 +0200 Message-ID: <312565511.gEFFlSTcEG@kreacher> In-Reply-To: <6ef6b96e-1772-6e80-60cf-eb57af618e99@gmail.com> References: <79b247b3-e056-610e-9a07-e685dfdaa6c9@gmail.com> <7332404.L1nL2KBT3s@kreacher> <6ef6b96e-1772-6e80-60cf-eb57af618e99@gmail.com> 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 On Saturday, July 6, 2019 3:02:11 PM CEST Thomas Lindroth wrote: > On 7/6/19 1:06 PM, Rafael J. Wysocki wrote: > > The patch is below, but note that it adds the tick stopping overhead to the idle loop > > for CPUs that are not adaptive-tick and when PM QoS latency constraints are used > > which is not desirable in general. > > > > Please test it, but as I said above, the real solution appears to be to treat adaptive-tick > > CPUs in a special way in the idle loop. > > > > --- > > drivers/cpuidle/governors/menu.c | 16 +++++----------- > > 1 file changed, 5 insertions(+), 11 deletions(-) > > > > Index: linux-pm/drivers/cpuidle/governors/menu.c > > =================================================================== > > --- linux-pm.orig/drivers/cpuidle/governors/menu.c > > +++ linux-pm/drivers/cpuidle/governors/menu.c > > @@ -302,9 +302,10 @@ static int menu_select(struct cpuidle_dr > > !drv->states[0].disabled && !dev->states_usage[0].disable)) { > > /* > > * In this case state[0] will be used no matter what, so return > > - * it right away and keep the tick running. > > + * it right away and keep the tick running if state[0] is a > > + * polling one. > > */ > > - *stop_tick = false; > > + *stop_tick = !!(drv->states[0].flags & CPUIDLE_FLAG_POLLING); > > return 0; > > } > > > > @@ -395,16 +396,9 @@ static int menu_select(struct cpuidle_dr > > > > return idx; > > } > > - if (s->exit_latency > latency_req) { > > - /* > > - * If we break out of the loop for latency reasons, use > > - * the target residency of the selected state as the > > - * expected idle duration so that the tick is retained > > - * as long as that target residency is low enough. > > - */ > > - predicted_us = drv->states[idx].target_residency; > > + if (s->exit_latency > latency_req) > > break; > > - } > > + > > idx = i; > > } > > I tested the patch and it appears to work. Idle CPUs now have ticks disabled even > when /dev/cpu_dma_latency is used. OK, thanks, but as I said previously, you'd see the problem again with the PM QoS latency constraint set to 0, which is somewhat inconsistent. Also, this fix is specific to the menu governor and the behavior should not depend on the governor here IMO, so I have another patch to try (appended). Please test it (instead of the previous one) and report back. > I also want to thank you for your work on the idle loop redesign. Overall it works > much better than before. I used to have a problem where idle CPUs would end up > doing C0 polling for a long time resulting in a big performance drop on the HT > sibling. When benchmarking I always had to offline siblings to get consistent > results. That problem was fixed in the redesign. > Thank you, much appreciated. --- kernel/sched/idle.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-pm/kernel/sched/idle.c =================================================================== --- linux-pm.orig/kernel/sched/idle.c +++ linux-pm/kernel/sched/idle.c @@ -191,7 +191,8 @@ static void cpuidle_idle_call(void) */ next_state = cpuidle_select(drv, dev, &stop_tick); - if (stop_tick || tick_nohz_tick_stopped()) + if (stop_tick || tick_nohz_tick_stopped() || + !housekeeping_cpu(dev->cpu, HK_FLAG_TICK)) tick_nohz_idle_stop_tick(); else tick_nohz_idle_retain_tick();