Received: by 10.213.65.68 with SMTP id h4csp1738705imn; Thu, 5 Apr 2018 03:00:20 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Bw+y1BIHMEbd4SABnOkOgrH/vaHEo+/OadM3/wR4BRM00hhhXP54RuDxUr1snWmS8y+f9 X-Received: by 10.99.115.4 with SMTP id o4mr14274718pgc.404.1522922420575; Thu, 05 Apr 2018 03:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522922420; cv=none; d=google.com; s=arc-20160816; b=0mRMUxoauQ/ib28WamiykwywAhVZzJh7f/g4fWRLgUBQ44QmTSX8Z1g4q3+kwj1Xjo 4VujRuadFx7UoFuiSeBuTR4XsrE1LIUwrvivhxAxytHGaCGptGHQG0ABiBjNl7jbjOEJ Ei1SmM6djWKchqI1+73r98ABJe45KblxY6CRwARzGPaWm0IRHsyXEQmxLJUU0EegvGK9 1vHIRJEW9bpVUSdvD9Tdg++gCjhop+ThG7LNhSDJgiQs/QHrtab8OgPGoYT5XJ3zc+7l OKMCNvLnb+Esil7Wko5BFS266qYHMFwKZvdmsFzkfbFAv0t11Zs8IuPrgMj7yfZyFLkW HrVg== 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=Pit6i0IV9gJ34fROK+sJfh41JaMOHkN3Snb39JIkYLU=; b=yg7kHUi1+pU9M1vDVIvQAtZcw67mf1v7Aqgd5dv64jiB0PkMba81zFMvEcwYfrKsa5 OdCgsEI6m9kkaM9xMeidncM1bayky2dX+n1hvDNQKzHgbAZy579fT0t3Jg6eezao7dPF +Pw6GFaZslpS+wNSKUbMvCKrF/TvpXgxGKVOdyGEd7DwLh5+FIYquoEWq9bz2Df34bK3 1lzOXAGEwZWMQsdXJd9lrJHA6Ealkc/DXDkzNWPk49SJZTCcmZ5i3ZoMqcuTVMnIfckD 6Pao9FJbKKHQEtnIdY/B6f+t4jajrs8K5TAudNUBqyKdZi/0kk7ZFanT81CIyb0nSx80 1QqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=WGPLn8WY; 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 f1si5104280pgt.385.2018.04.05.03.00.06; Thu, 05 Apr 2018 03:00:20 -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=WGPLn8WY; 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 S1752491AbeDEJ7I (ORCPT + 99 others); Thu, 5 Apr 2018 05:59:08 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:40850 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752016AbeDEJ7B (ORCPT ); Thu, 5 Apr 2018 05:59:01 -0400 Received: by mail-pl0-f65.google.com with SMTP id x4-v6so18381438pln.7 for ; Thu, 05 Apr 2018 02:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Pit6i0IV9gJ34fROK+sJfh41JaMOHkN3Snb39JIkYLU=; b=WGPLn8WYoJFOOppqCC/d/HR8j7DQ8SLYUr8pYfyIR7JU42nP8iqLEJkQLEX+LbzdrZ dZGYDeH56Lkrqt7yDUg06UwYFSEXRznSBjLBnmc0gk2PH0OKpq/c30tD/WoFW0XchXlG 8mNQvUcjh9SY5YzKMUmQF2OBmAgJYwwhWVfwg= 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=Pit6i0IV9gJ34fROK+sJfh41JaMOHkN3Snb39JIkYLU=; b=bZK7XiwFSoP4Mc/zd5wEjAcSz57EAZu6VAhpB0hXZVi9121rWYkRek2XRBrUnz/NWg mqZhhZfaRF+XU0idlk84HnQ7CKqCmYCuRZ6DkJmYPjgLsJYjY3Kq98UyicPM+EeHUeED uEr0/f4yBxIVBLz1u4K0B9QRABTLEbtTfUm6l3PFAsC95r88mpcuiYBZU6q4ukZB+6+4 SFrdD4bAZtTwgxp8iaJGVvYwfC8rFmQ+vXTZG1JRLSBwa4sKBmELrC6lwBF1WmTsliB6 ZVejcKCgALtUjl8qmId6Agm1JAHVAu4GBmiIbUnWz5ilxvrFlgwXwo0CwYxKy8/W9SQc c7nw== X-Gm-Message-State: AElRT7F1UMtdnagALT2MMaL45o6Rk++Ht9OtxMPzLMMLup820mobESQn J1kqIj9SNXDeKX0fJ4O8K7jG2Q== X-Received: by 2002:a17:902:207:: with SMTP id 7-v6mr22541900plc.261.1522922340982; Thu, 05 Apr 2018 02:59:00 -0700 (PDT) Received: from localhost ([122.171.228.188]) by smtp.gmail.com with ESMTPSA id z127sm13685356pfb.72.2018.04.05.02.58.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 02:59:00 -0700 (PDT) Date: Thu, 5 Apr 2018 15:28:58 +0530 From: Viresh Kumar To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Subject: Re: [PATCH] cpufreq/schedutil: Cleanup and document iowait boost Message-ID: <20180405095858.GP3572@vireshk-i7> References: <20180328090721.26068-1-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180328090721.26068-1-patrick.bellasi@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28-03-18, 10:07, Patrick Bellasi wrote: > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 2b124811947d..c840b0626735 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -201,43 +201,80 @@ static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu) > return min(util, sg_cpu->max); > } I like the general idea but there are few things which look incorrect to me, even in the current code. > -static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, unsigned int flags) > +/** > + * sugov_set_iowait_boost updates the IO boost at each wakeup from IO. > + * @sg_cpu: the sugov data for the CPU to boost > + * @flags: SCHED_CPUFREQ_IOWAIT if the task is waking up after an IO wait > + * > + * Each time a task wakes up after an IO operation, the CPU utilization can be > + * boosted to a certain utilization which is doubled at each wakeup > + * from IO, starting from the utilization of the minimum OPP to that of the > + * maximum one. You may also want to write here that the doubling of boost value is restricted by rate_limit_us duration, its not that we double every time this routine is called. > + */ > +static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, unsigned int flags) > { > > - /* Clear iowait_boost if the CPU apprears to have been idle. */ > - if (delta_ns > TICK_NSEC) { > - sg_cpu->iowait_boost = 0; > - sg_cpu->iowait_boost_pending = false; > - } So this is the only difference in this routine, everything else is re-arrangement IIUC. There is a problem that I see in existing code as well as code after this commit. Consider this sequence of events on a platform where cpufreq policies aren't shared, i.e. each CPU has his own policy. sugov_set_iowait_boost() gets called multiple times for a CPU with IOWAIT flag set that leads us to a big boost value, like fmax. The CPU goes to idle then and the task wakes up after few ticks. Because we are first checking the IOWAIT flag in this routine, we will double the iowait boost. Ideally, based on the TICK_NSEC logic we have, we should have first set the iowait boost to 0 and then because the flag was set, set the boost to fmin. So the order of this routine needs to get fixed in the first patch. The same problem can happen for cases where the policy is shared as well, but chances are less. > -static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util, > - unsigned long *max) > +/** > + * sugov_iowait_boost boosts a CPU after a wakeup from IO. > + * @sg_cpu: the sugov data for the cpu to boost > + * @time: the update time from the caller > + * @util: the utilization to (eventually) boost > + * @max: the maximum value the utilization can be boosted to > + * > + * A CPU running a task which woken up after an IO operation can have its > + * utilization boosted to speed up the completion of those IO operations. > + * The IO boost value is increased each time a task wakes up from IO, in > + * sugov_set_iowait_boost(), and it's instead decreased by this function, > + * each time an increase has not been requested (!iowait_boost_pending). > + * > + * A CPU which also appears to have been idle for at least one tick has also > + * its IO boost utilization reset. > + * > + * This mechanism is designed to boost high frequently IO waiting tasks, while > + * being more conservative on tasks which does sporadic IO operations. > + */ > +static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, u64 time, > + unsigned long *util, unsigned long *max) > { > unsigned int boost_util, boost_max; > > - if (!sg_cpu->iowait_boost) > + /* Clear boost if the CPU appears to have been idle enough */ > + 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; > + } > return; This looks incorrect. I have read this 10 times and it looked incorrect every single time :( The "return" statement should be part of the if block itself ? Else we will never boost. > + } > Now we can reach here even on !sg_cpu->iowait_boost which wasn't the case earlier. Though we will eventually return from the routine without doing any damage, but we will waste some time running useless if/else expressions. Maybe still have something like if (!sg_cpu->iowait_boost) return; ?? -- viresh