Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp576284imm; Mon, 21 May 2018 10:35:59 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr6zBXSjhVlToliyzX+LUZp+MKfLitc/ibOo4ariUbSa1ZIVSlnWivV5mmKfAaH/ZASazZi X-Received: by 2002:a17:902:42c3:: with SMTP id h61-v6mr21250517pld.164.1526924159108; Mon, 21 May 2018 10:35:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526924159; cv=none; d=google.com; s=arc-20160816; b=sBDSXX2Y3w2fLYKrzP812/FaM9WUZ0DsUYWKq6s6Ksh/16vigwWUkf8MKkQQDWEtco 01BRLDbNrVuybqA00ktCLamN213L2hd1Qmsi/CmwbGi7lVgzlZKDze9kbsi3mOqEYEIa A0204Y7CgTXnOs0jZgX8J9iUG8bsdgKHDRfoYxmW5of/h6WYNX1WQdQGEDVHErUfzrqY qmPWkgSlyvQwOo13x0/h/5p67F9jDoMceKvweMX3f0R8x/XbW0niAv2SH2MdECwl3L13 aMvnRbKV7NC7svsBq/3yFr6GMLsl+nUh8eMuaa1wsC9SYWyAtVEjBntZBzZ+oHmjI8qY 6fGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=YabJKzF41Psv56XhJlEKK4g1vFPOizH0FTDP+P0p89E=; b=JJ8HkScbZ9ynYGmnpiximSq2+KAXAlCYSOcYG3m0I/61LgJofpdsUoQEk8fOOBml2X uE8w6+6VatRKbZ6dAeH1lTJ3Qe5myavwZ7B4zdC66+HHVQUpJeE05t/y5jsxfd6eX1Aw xFYEY874EeA5bwtVNvgFkVKzHtYxCVDl57GG6viO8etagz7Dyg19YMzCBh5HSjHFjv3x mvWCRJy9g/pgy16hqoHgJVikU/tZYyAAxe3/SxwVey3u9qHhAWzJvP0X9bSG68fJ5dot JN/WYD+FVCk72fgVlnnI1Yiy6gNDi8nBW3xi5Ecj7oMCUKZYNrhSasKUnGTj5xAHcE7a 2m6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=ueCIOvcJ; 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 k75-v6si14080668pfk.369.2018.05.21.10.35.44; Mon, 21 May 2018 10:35:59 -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=@joelfernandes.org header.s=google header.b=ueCIOvcJ; 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 S1753325AbeEUReB (ORCPT + 99 others); Mon, 21 May 2018 13:34:01 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:34946 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753303AbeEURd6 (ORCPT ); Mon, 21 May 2018 13:33:58 -0400 Received: by mail-pl0-f65.google.com with SMTP id i5-v6so9200053plt.2 for ; Mon, 21 May 2018 10:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YabJKzF41Psv56XhJlEKK4g1vFPOizH0FTDP+P0p89E=; b=ueCIOvcJC9Pi7/eN0NbJm6cG1SGfpEzyizmxYNNDhtBmUvtvpeHNbquVrGdz9QVNPN lLSR7FS0aWbuomQ+m1zTH1hJBaoiFlG5ZteurG+5YS0q1m5UCXEpwgrqsh+yjgoSjLvP Jp4lMPMO4XmL3I+uQrZkVeEuQdWPSIp8DK9Ss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YabJKzF41Psv56XhJlEKK4g1vFPOizH0FTDP+P0p89E=; b=rjjmD1xSIyH1ffUqJJbmSzjsBkEQ5k/s/tmQQKNmi/j1Lksx31oN+V18cS219goTpj L+V1mr3TwJieciFrbyMur/Xm9YjqArLWLJcD84r5oLcD8cZYgro3oxe13xNPmiBjoiWt QTA70iIkeQqP8310AU+XXUv8KYbCWNIDWLMV4dB9+F8MeXb9Wk1GgvAb1cWsf89P18R4 e0gJoTtxdHHeRMmI9Va5GbwCzYNR5VZ66Hl3k3cgR7+eIVf54eHUntvxVJSoqhaN2Lmp uLqjn6ynTZzmnxV2YsQZNWZ7SxdlLB5Z4qN9n7mwzn0CldSv1nw595DKPCNl4aZ1e/qT 1/9A== X-Gm-Message-State: ALKqPwcfyYQcIP8IVA1ZeYgaSM+vKKISsBhabyFZ0p5xllYGShcYXhFm QPpkvj+lW4/Ynx0/aZZNGfHedw== X-Received: by 2002:a17:902:b483:: with SMTP id y3-v6mr21068384plr.157.1526924037848; Mon, 21 May 2018 10:33:57 -0700 (PDT) Received: from localhost ([2620:0:1000:1600:3122:ea9c:d178:eb]) by smtp.gmail.com with ESMTPSA id n18-v6sm34035965pfg.36.2018.05.21.10.33.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 May 2018 10:33:57 -0700 (PDT) Date: Mon, 21 May 2018 10:33:56 -0700 From: Joel Fernandes To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Dietmar Eggemann , Juri Lelli , kernel-team@android.com Subject: Re: [PATCH v3 1/2] cpufreq: schedutil: Fix iowait boost reset Message-ID: <20180521173356.GB21678@joelaf.mtv.corp.google.com> References: <20180521085120.7902-1-patrick.bellasi@arm.com> <20180521085120.7902-2-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180521085120.7902-2-patrick.bellasi@arm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21, 2018 at 09:51:19AM +0100, Patrick Bellasi wrote: > A more energy efficient update of the IO wait boosting mechanism has > been introduced in: > > commit a5a0809bc58e ("cpufreq: schedutil: Make iowait boost more energy efficient") > > where the boost value is expected to be: > > - doubled at each successive wakeup from IO > staring from the minimum frequency supported by a CPU > > - reset when a CPU is not updated for more then one tick > by either disabling the IO wait boost or resetting its value to the > minimum frequency if this new update requires an IO boost. > > This approach is supposed to "ignore" boosting for sporadic wakeups from > IO, while still getting the frequency boosted to the maximum to benefit > long sequence of wakeup from IO operations. > > However, these assumptions are not always satisfied. > For example, when an IO boosted CPU enters idle for more the one tick > and then wakes up after an IO wait, since in sugov_set_iowait_boost() we > first check the IOWAIT flag, we keep doubling the iowait boost instead > of restarting from the minimum frequency value. > > This misbehavior could happen mainly on non-shared frequency domains, > thus defeating the energy efficiency optimization, but it can also > happen on shared frequency domain systems. > > Let fix this issue in sugov_set_iowait_boost() by: > - first check the IO wait boost reset conditions > to eventually reset the boost value > - then applying the correct IO boost value > if required by the caller > > Reported-by: Viresh Kumar > Signed-off-by: Patrick Bellasi > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Rafael J. Wysocki > Cc: Viresh Kumar > Cc: Joel Fernandes > Cc: Juri Lelli > Cc: Dietmar Eggemann > Cc: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > Fixes: a5a0809bc58e ("cpufreq: schedutil: Make iowait boost more energy efficient") > > --- > Changes in v3: > - split the fix into a separated patch (this one) > - added "Fixes" tag (Viresh) > --- > kernel/sched/cpufreq_schedutil.c | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index e13df951aca7..c4063e578e4d 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -203,6 +203,16 @@ static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu) > > static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, unsigned int flags) > { > + /* Clear iowait_boost if the CPU apprears to have been idle. */ > + if (sg_cpu->iowait_boost) { > + s64 delta_ns = time - sg_cpu->last_update; > + > + if (delta_ns > TICK_NSEC) { > + sg_cpu->iowait_boost = 0; > + sg_cpu->iowait_boost_pending = false; > + } > + } > + Yes, I guess this effects single policies only. For shared, we are resetting the iowait boost on the wake-up-from-idle update anyway. So even if it was doubled, it would be reset. Looks good to me! thanks, Reviewed-by: Joel Fernandes (Google)