Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1601354pxb; Mon, 22 Feb 2021 06:22:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfpAU4xxtBhaqzaPSfeJl/FAdJLlBiqzfarENXnLTBEnD4nv+ELFYYaCS7cED2Y/JADZvP X-Received: by 2002:a05:6402:10c8:: with SMTP id p8mr22037257edu.144.1614003778439; Mon, 22 Feb 2021 06:22:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614003778; cv=none; d=google.com; s=arc-20160816; b=Q2Ad/jZ6GbwxJYG0idvTtJWiqLt/FdnMOv0oNJgaP+Ndu5ILw5Rz2cy8mbsll2S+Qc q4tB7tA8O+T+rpEVnbyIvsJkRq4c8lZgz7133IoiQv8gR/1QceKa70j1VW25wE1B1adj t4gVvIckXcvT27lxJ7V13hq+9M8lt1g18xj43+1Nr0eVGjvq9b2PoC8Jn/SFEjJhx/7n Gb5arVQwyfAdWUJQsL4JZza06ctmb01iwUuVKly6iaLIaTK2mX/O4fioRgmVj+hNIc1q QwWMTmEqVqrSFfmUt5AiCJ5WTTJ+0FujMMkGZL3s5Ax4J4zA9Bgxn5sVdgHw7A6Mavnq rZPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=GvcCrCM141fUU/BWS1+ek65DoVTCnDSGKRfT0AdtWHI=; b=II2s4SsjcJbY/T9oEMeJQspCVF+6KQclmuM/OGawsCiFt9zhs3Z3Nc1f4WHaSGs/za ktr/1l59Mi+pFNqU8c7LH4wCBSOEarAq2bh3GVk+PY+mapS1n8Bn09B6OnJtQCnDwM2K H0aQg9azBUh2puOLPupfkok7yG4GMieYEde9PUDsN4WhQaAa0LuS6ewNOczp+6Hr77Yn iXnzmmO+NhfTP+XRbpKUDsvbcWPv5kcfDO0wiWvUTZ7VM5FRvbZVDqKz+HMyh71oBzMv xgaXPhYSalAIj4aHh9AmQNiJuBkkO6H92BHFHu/zhrWl67105edo9YGqliFzeb8KVNdF uecQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@163.com header.s=s110527 header.b=jP6Aaf3B; 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=163.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hr20si10545276ejc.23.2021.02.22.06.22.35; Mon, 22 Feb 2021 06:22:58 -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=@163.com header.s=s110527 header.b=jP6Aaf3B; 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=163.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231360AbhBVOVq (ORCPT + 99 others); Mon, 22 Feb 2021 09:21:46 -0500 Received: from m12-12.163.com ([220.181.12.12]:51883 "EHLO m12-12.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232050AbhBVN5O (ORCPT ); Mon, 22 Feb 2021 08:57:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:Message-ID:MIME-Version; bh=GvcCr CM141fUU/BWS1+ek65DoVTCnDSGKRfT0AdtWHI=; b=jP6Aaf3BaNJfyOQvobyyh WQjLtwks9fwzgolijAwtnHB5eqM7HGaSveOAgb+5uPbI9DNLELRNld4NE8JdoE68 f4iF89IGBZf2NYtKsHg1YgNbVaLPFIm920l7VVvCFC9gmZEuOUU6xs0V9Azc+3tf fE9CrHmiqniCX1X2APShEA= Received: from localhost (unknown [218.94.48.178]) by smtp8 (Coremail) with SMTP id DMCowAAXvcGIczNgtAbiRg--.3363S2; Mon, 22 Feb 2021 17:04:10 +0800 (CST) Date: Mon, 22 Feb 2021 17:04:20 +0800 From: Yue Hu To: Viresh Kumar Cc: Yue Hu , rjw@rjwysocki.net, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, huyue2@yulong.com Subject: Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to busy CPU if need_freq_update is set Message-ID: <20210222170420.000019a3.zbestahu@163.com> In-Reply-To: <20210222053014.s45odi3qsfio2ahp@vireshk-i7> References: <20210218082514.1437-1-zbestahu@gmail.com> <20210218102029.syj6vkltlbtoxsig@vireshk-i7> <20210219113804.00004a7e.zbestahu@gmail.com> <20210219040933.2o5hhbjb6emf3xl4@vireshk-i7> <20210219144140.00004de9.zbestahu@gmail.com> <20210219074249.2hcwcnakihor343h@vireshk-i7> <20210219162026.00002e2b.zbestahu@gmail.com> <20210219093551.bykqhjk6xvs4kszi@vireshk-i7> <20210219194509.00005884.zbestahu@gmail.com> <20210222053014.s45odi3qsfio2ahp@vireshk-i7> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CM-TRANSID: DMCowAAXvcGIczNgtAbiRg--.3363S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7ZF45Ary5ZFW5ArW5tF4fZrb_yoW8KF4xpF W5Ca9Yvw1DK34kXwn3tF15XFW5XanrA34FgF45Gwn5ZwnFg340grW0ga17CrW5CrnYkr1S yr1jqF9FyF1xZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j0OJ5UUUUU= X-Originating-IP: [218.94.48.178] X-CM-SenderInfo: p2eh23xdkxqiywtou0bp/1tbiTwpBEVsGXuC4XAAAsS Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 22 Feb 2021 11:00:14 +0530 Viresh Kumar wrote: > On 19-02-21, 19:45, Yue Hu wrote: > > We will set next_f to next_freq(previous freq) if next_f is > > reduced for busy CPU. Then the next sugov_update_next_freq() will check > > if next_freq matches next_f if need_freq_update is not set. > > Obviously, we will do nothing for the case. And The related check to > > fast_switch_enabled and raw_spin_{lock,unlock} operations are > > unnecessary. > > Right, but we will still need sugov_update_next_freq() to have the > same implementation regardless and so I am not sure if we should add Yes, sugov_update_next_freq() should be keeping current logic for corner case. > this change: > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > index 41e498b0008a..7289e1adab73 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -362,6 +362,9 @@ static void sugov_update_single_freq(struct update_util_data *hook, u64 time, > * recently, as the reduction is likely to be premature then. > */ > if (sugov_cpu_is_busy(sg_cpu) && next_f < sg_policy->next_freq) { > + if (!sg_policy->need_freq_update) The initial purpose about code of `next_f = sg_policy->next_freq` here (for special CPU busy case) should be skipping the freq update. Since commit 600f5badb78c ("cpufreq: schedutil: Don't skip freq update when limits change"), we add the check to busy CPU for not skipping the update, we need to update the freq using computed one because limits change. After commit 23a881852f3e ("cpufreq: schedutil: Don't skip freq update if need_freq_update is set"), we removed the need_freq_update check(no issue of commit 600f5badb78c anymore?) and introduce to always do an update in sugov_update_next_freq() if need_freq_update is set even though current freq == sg_policy->next_freq because of corner case issue. But that is conflict with original purpose of the freq skip code (next_f = sg_policy->next_freq) of busy CPU. > + return; > + Yes, it's what i want ot add for unnecessary behaviors i mentioned above. Add return here should just be for skipping update(different from corner case in commit23a881852f3e). > next_f = sg_policy->next_freq; > > /* Restore cached freq as next_freq has changed */ > >