Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1328776pxb; Sun, 21 Feb 2021 21:33:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJzLvG6b6tqQHl4iIfq03hfOmG8zFz8F90ISYLh+cLa2qjnsnu+oUZDzu8rx+n3lxZtHgld+ X-Received: by 2002:a50:8b66:: with SMTP id l93mr20390474edl.384.1613972005540; Sun, 21 Feb 2021 21:33:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613972005; cv=none; d=google.com; s=arc-20160816; b=QE71p5R+sF38w6b3mjJKQJWz52CUB4ZrpwOctJHFWn/iJxecBWQFOtFHx4wMtj2zwN xJPwmPH7L6zzF04K/RJcp4xdRbuMCffZggOMnYzBaohyOUXugiePmciy/JN2tSaddnXj nEZBZ/2NIaHh2V30UJvcIW9f3tjGeWhD9qWMBnFONVnHCa6dKzbP+1uMSds8vyWVrxPl imZuo0+u36Ux7ikXQXq+3Ketu3AiBkQQRr4xlmlTq5yrRjGqqGEPG43WOGaNFzgf2kmg OaxBMPQTFA8eVP2izqhVGBhBEnav1gbEbWzdOG5hF9WIOX9vQAYMKvFmbEmqm19gt204 tyTg== 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=88bCU0wVX0zazGnaAQhw1Te7NFEOR8aLunDEDqQi1Z4=; b=rkKPEBF8G893kOERBvC++6Ut7fh5PQ9XgNz64aWOT8daODju2hW6EaRHrXmHOIVZGj BFnVCuMWVN5NHWPfGqhR9+DpFZegZJwsU3h3UR9PPCWLUXzR2NoIaI2s7HuLJv1migKl DMkWxjgoOKDhblJhOz3H4jfhVm3XENZTbrXgpiK88xhGGYT/89+pGYS/j+q7DuM4ITEC gTERhZ+ZSDqXNmWmpjH/Q6TtW5ApZjKVya+0ipVTIm/HjwIkW7ZS/e8ugR0sW1WRxmRX WXRcB0vX7ST7Hl3DGiH79t9n0N6ZsJqkxpGyXizK0ZLUye2S/R5+nr9xpFHg2wJVdqTl Cu0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="Y/5/Ig06"; 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 kg13si10402131ejc.670.2021.02.21.21.33.02; Sun, 21 Feb 2021 21:33:25 -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="Y/5/Ig06"; 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 S229903AbhBVFbA (ORCPT + 99 others); Mon, 22 Feb 2021 00:31:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbhBVFa7 (ORCPT ); Mon, 22 Feb 2021 00:30:59 -0500 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA619C061786 for ; Sun, 21 Feb 2021 21:30:19 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id f8so7033666plg.5 for ; Sun, 21 Feb 2021 21:30:19 -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=88bCU0wVX0zazGnaAQhw1Te7NFEOR8aLunDEDqQi1Z4=; b=Y/5/Ig063lR7XiqKZl8egup3Bw/7Q79fv9uidDgZJ+d31Fed4RfdYAYDgNcOiMkLle DiBlIUsEBr4EpfSA5eE30xl0LdLAWTmxvEEPSmvwE/C5yfxk3dcwoYw37+Sssqa875Jx 9p6aRBt1TbGorSxSmzd7cPS4NoT1DDEins0tvkz+pcdSzVdfMhBKFPDnUCsvZyCy+obe zhjFNOTS5+GX5tsls6GlwrBiUlhtoEvrSaJCTTrgS8S3b7CZtrd6EAz7JSsaJwf/7Swd yfNQ10331+hrXcep02vkjKD0h8paB/IsoEckuIySzjw9gSB2vqBQSeB6rcf7pPbzLkFN nbJQ== 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=88bCU0wVX0zazGnaAQhw1Te7NFEOR8aLunDEDqQi1Z4=; b=amx3yEUUQHyE+FgC1wcc5QLsD0/84aVI53KV9Io8W+Qxuadq56/foFNVrKI50we5Fl i5WN1eZrJiGEi/MJhvyf1QX8FxkBL2+8Th/APJZiuIFcmYTcEDTB9EOR4dSZPlyQCmnW 15DT4EAafX0YVcfV/ZMyeq3GbLF7rIe1z0hxJjEdupZCLCGezSQEvJkTCtCucXHMKSHW D5mbjlUmOKxMNZBYlin3iDOJiCb0nqbfavDoBReAybTqXvyQgaR2TwF+obF935Dno+XY jI+PYgmMg9EWkiyLd/fFQ/q5hHFpGCFUHvi2BP2Yy/iGgHhCSIvXSDASidG3F6a42DGt GlWg== X-Gm-Message-State: AOAM531laG5wwLjIfOmayH3CnYX8p+7TsJS+SH3QOZX0Dff6o89+VSgu Vjvs9C7Ro1wibTRFt+nOcEHsGw== X-Received: by 2002:a17:90a:1503:: with SMTP id l3mr21543094pja.41.1613971819001; Sun, 21 Feb 2021 21:30:19 -0800 (PST) Received: from localhost ([122.172.59.240]) by smtp.gmail.com with ESMTPSA id w203sm9743518pff.184.2021.02.21.21.30.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Feb 2021 21:30:17 -0800 (PST) Date: Mon, 22 Feb 2021 11:00:14 +0530 From: Viresh Kumar To: Yue Hu Cc: 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, zbestahu@163.com Subject: Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to busy CPU if need_freq_update is set Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210219194509.00005884.zbestahu@gmail.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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) + return; + next_f = sg_policy->next_freq; /* Restore cached freq as next_freq has changed */ -- viresh