Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3016382pxu; Tue, 8 Dec 2020 00:55:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJzNh8a7mPJ6V8eC4R+e2lC6wx9HxrZU92VBF4fRlan+cjsCiizG0UMAi8ZLvY/pweE8I0fR X-Received: by 2002:aa7:d7d2:: with SMTP id e18mr10748138eds.256.1607417747933; Tue, 08 Dec 2020 00:55:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607417747; cv=none; d=google.com; s=arc-20160816; b=0VM+dLKUz3B2+T39Y4+a5xLHFV6C0IRRgGC/+6C9N4u910r7VZBKWhe5oK0EP7j2oP WBmGjNWcXgM11YG1HmbeoIeXZvipYFORVSmYOMORKTYNO2vBDnazl1IBQDxwUQW42hLP e9cjUSYldex3t9KvgGmgMW5Hbd/SeeThfaOQKFJmI4p8AYej6zxxGE6MZVwUzHoUJQ7H vvx24LGveM1kctaMKBn9LJnwujCKhv9HwMdOABPugt47VwpPSddK0hjGyf6Lclq1lx6a VUHioZsX+sFafOjz8DAYQyEIgsqt+r943M87pU3L5bkO3gLzIwWrA1b/bMePksYq6efn sRVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=4EpXoHXL4k0cYEYjbXCM3qqNNX/ao/lS1FFGU2tbAsI=; b=pfk14ylESRYhi7DCbi8mlv6U9hooYXBlchvX+HuiHtyVeDRhnX2Lz654hXeBH6hcvN 0CKzDiW+3NJzT8MZMucTK5Ntb05js/hGoUh+Al4OpKYoLsxrm5MSEv9Ew+K8kgSF1c9N ZzoU9XHe43+5rKakvuf/V6sk2ZJnR8hYvB6PBt1/yDN7ohXCnsJbQj+sNNqeNAyHeCbf irRhOvTjqkHdItVb/P7frrxgcwcTBwKXGrQyd0EQzmskWzwF8WJb7TJrSls1lnbRvn3Z 2NS2oBcbNgAr0VSwL4wR04EI0LiJSqjac7rp9vcyy5xa/0rjRBcjmMrouC7erslOKz35 awWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=npafHANG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id 88si9781222edr.151.2020.12.08.00.55.25; Tue, 08 Dec 2020 00:55:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=npafHANG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728535AbgLHIwg (ORCPT + 99 others); Tue, 8 Dec 2020 03:52:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728512AbgLHIwg (ORCPT ); Tue, 8 Dec 2020 03:52:36 -0500 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40BE8C0613D6 for ; Tue, 8 Dec 2020 00:51:50 -0800 (PST) Received: by mail-pg1-x541.google.com with SMTP id o5so11585949pgm.10 for ; Tue, 08 Dec 2020 00:51:50 -0800 (PST) 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=4EpXoHXL4k0cYEYjbXCM3qqNNX/ao/lS1FFGU2tbAsI=; b=npafHANG5pXcGj4u2NdXisvah9MRC0V7E4vMXhflCDTzfT9Qe0koYZDXIDRY6Y05mt hEfBYI7dpxRFVMEvBVY9TZhBWiM3Lro1HfeWmMpoksUFutBn0sDFqAEsMV7F4Kz+LGBd jqDlXEoMkuHatGoik1tgSb4zyBTj3ujruNA/Cw41TOye5EX/9m9sf3yAG9aknrsWOVX2 CmySvEeotBmGCZpwmOTgb9I2TtO+TLQryAryqm6YV/JA7nPOKZE1RrSieFZRqmfaf7QV n3eDQJUXilGaKFbL2+MIkj7KpG2Q5YYt38+euySILQmt1Icx7qYL8ScvZSMt9HtSAVNF 1VmA== 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=4EpXoHXL4k0cYEYjbXCM3qqNNX/ao/lS1FFGU2tbAsI=; b=Se8nskO5yRfqN5og13LMbxTjxw5pl+9eoVFmiNfD13NBfg4TLd24PGawD2zUvk56Kd SM2zJ3K/EXgEmQIv5KASscfBPA+QWDSOrezDZab4VveaFgpnGFrrj44QYfW1V5QdxdU8 lvtX+daUVH3iOhcVEdYhLb6ueR5F5sn07UEDXjRgQ3LUMtFxdcU/T43WyeFq8lzBuoW7 +Cmi3iOqHl6uNG4xlpo9mG0otCc+UXeS769r/hXO1HKIMLNV7ZBZ65TnZTGP7Se6Nsn6 1u65TCBsbyVRVeo5KBuUw0C1R7TNZ8WwgqupQ6N7RtwAmsYhqaAtYWWGjHXNZsVQ+EPZ hViw== X-Gm-Message-State: AOAM532KLtnDzxdsNtnEUNqOybtPusfqZB0SO7/aiCFnl0yhvfDnMhFf XdhJbEpt466AvhLve8RpnBK2ELOxj6ZeNw== X-Received: by 2002:a17:90a:6f42:: with SMTP id d60mr3298129pjk.44.1607417509662; Tue, 08 Dec 2020 00:51:49 -0800 (PST) Received: from localhost ([122.172.136.109]) by smtp.gmail.com with ESMTPSA id e29sm14173828pfj.174.2020.12.08.00.51.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2020 00:51:48 -0800 (PST) Date: Tue, 8 Dec 2020 14:21:46 +0530 From: Viresh Kumar To: "Rafael J. Wysocki" Cc: Linux PM , LKML , Srinivas Pandruvada , Peter Zijlstra , Doug Smythies , Giovanni Gherdovich Subject: Re: [PATCH v1 2/4] cpufreq: schedutil: Adjust utilization instead of frequency Message-ID: <20201208085146.pzem6t3mt44xwxkm@vireshk-i7> References: <20360841.iInq7taT2Z@kreacher> <1916732.tSaCp9PeQq@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1916732.tSaCp9PeQq@kreacher> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07-12-20, 17:29, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > When avoiding reduction of the frequency after the target CPU has > been busy since the previous frequency update, adjust the utilization > instead of adjusting the frequency, because doing so is more prudent > (it is done to counter a possible utilization deficit after all) and > it will allow some code to be shared after a subsequent change. > > Signed-off-by: Rafael J. Wysocki > --- > kernel/sched/cpufreq_schedutil.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > Index: linux-pm/kernel/sched/cpufreq_schedutil.c > =================================================================== > --- linux-pm.orig/kernel/sched/cpufreq_schedutil.c > +++ linux-pm/kernel/sched/cpufreq_schedutil.c > @@ -437,7 +437,7 @@ static void sugov_update_single(struct u > { > struct sugov_cpu *sg_cpu = container_of(hook, struct sugov_cpu, update_util); > struct sugov_policy *sg_policy = sg_cpu->sg_policy; > - unsigned int cached_freq = sg_policy->cached_raw_freq; > + unsigned long prev_util = sg_cpu->util; > unsigned int next_f; > > sugov_iowait_boost(sg_cpu, time, flags); > @@ -451,17 +451,14 @@ static void sugov_update_single(struct u > sugov_get_util(sg_cpu); > sugov_iowait_apply(sg_cpu, time); > > - next_f = get_next_freq(sg_policy, sg_cpu->util, sg_cpu->max); > /* > * Do not reduce the frequency if the CPU has not been idle > * recently, as the reduction is likely to be premature then. > */ > - if (sugov_cpu_is_busy(sg_cpu) && next_f < sg_policy->next_freq) { > - next_f = sg_policy->next_freq; > + if (sugov_cpu_is_busy(sg_cpu) && sg_cpu->util < prev_util) > + sg_cpu->util = prev_util; > > - /* Restore cached freq as next_freq has changed */ > - sg_policy->cached_raw_freq = cached_freq; > - } > + next_f = get_next_freq(sg_policy, sg_cpu->util, sg_cpu->max); I don't think we can replace freq comparison by util, or at least it will give us a different final frequency and the behavior is changed. Lets take an example, lets say current freq is 1 GHz and max is 1024. Round 1: Lets say util is 1000 next_f = 1GHz * 1.25 * 1000/1024 = 1.2 GHz Round 2: Lets say util has come down to 900 here, before the patch: next_f = 1.2 GHz * 1.25 * 900/1024 = 1.31 GHz after the patch: next_f = 1.2 GHz * 1.25 * 1000/1024 = 1.45 GHz Or did I make a mistake here ? -- viresh