Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp765894pxb; Wed, 24 Feb 2021 14:37:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJxKFThQQfKa6JvJAXkKk75/h60WrUvArX7yNEL1wn5ya3S8V+sKeFtdnw95AQUnDkqrcu3i X-Received: by 2002:a17:907:7893:: with SMTP id ku19mr26081701ejc.245.1614206244198; Wed, 24 Feb 2021 14:37:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614206244; cv=none; d=google.com; s=arc-20160816; b=kBfCX4EaaBOJD8QAXHHVLDcYRyrc71eof25aOJOlx/JWL59U0QrdN4jYkzL4iEAdCC GCYy3okThQsy5/8QVhPt9QRQm+z2Yfn11xA+oxbD4vc83L/QhbW8QeD0sLPSCn3SbNG9 s7c0jKHBYLVyfDkHXfRG6Xo/i5dm66sSZIQFWabTaTDQoA24hH+Gc4qdJRADmgrXutqE 0AK6lUCUo5CBwSqJrc0uCpKOkfuoOdHB/I6dl1vg1esZlE4t0te10NoS8OgaYyowGGED luqDqZqFP3eEO/MN8bEE8SfeTwCz2RhSV93NGkRDZ3ynJFDV3xrUsvItvY59MXAxITFI P2DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=6jB0IWEXg2hyE52rBNDsQmAI4TXSzoyWftlUHEZ3npU=; b=xCYVUaq4bUZ6rUMXsv7Wank/qI+fNWnGkHpY2oeO+qY/MZB5qyU8S3rqYkzBj9dSE9 hJegLdT4qN3IjqfJM4Rw6P64d6IF0TqpgibWH0I4iUDeq3MdXYXja8LJ1z1ao7DLXdXf 3z+VFxvXtu1HykuS4vw0TiSRZW7T+HcGV9EJAScvJ/RWAzRTBloymqE/uEbc9MBNbjTF j0ZqVlKXytuMZZhXcFoAuEpZJUPOSq8uiGm+l1fuBbsnFGaK2YKDiASURtcNEX7aD79I RPDRgcEeJc8slaS3y+f8HQMIyx5jT3ImvYQqtEdf0kI8KvyVUuiIw94zN78wlhNuEUV+ PuYw== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dp16si2208723ejc.564.2021.02.24.14.36.38; Wed, 24 Feb 2021 14:37:24 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233597AbhBXMrH (ORCPT + 99 others); Wed, 24 Feb 2021 07:47:07 -0500 Received: from mail-ot1-f48.google.com ([209.85.210.48]:40025 "EHLO mail-ot1-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231810AbhBXMrD (ORCPT ); Wed, 24 Feb 2021 07:47:03 -0500 Received: by mail-ot1-f48.google.com with SMTP id b8so1983479oti.7; Wed, 24 Feb 2021 04:46:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6jB0IWEXg2hyE52rBNDsQmAI4TXSzoyWftlUHEZ3npU=; b=sT+lh+Leju4gBXc6zaymHskmfw+c5bFqoI7nlDxz8V8lK8UGlHagZP+46m9IYY8U4K YL1qQNYOX9fRNzJyEFOZMVqrxQ3oou1EIQnJccavsGdsyi2IgAtPTA40Wir4ZPfGgJ/+ 30VB7CwrKSisyvMsQ/8027zz8cfZr4dr4iyRCEhuFQU3RtN3NY4aL2Ro7H0WUH9rb0kM Uo9uDdNw3N44xf+XPd2rv6fIQp603sJQn0/efE2nch3C2nTiw88eYmjKnBQqK/TQcc9u mrjUQfmKVyXaL/8WAseaumZao+tEfbEgcQa4yhDLB4prjI3Kl6oHAl+H0eA0TUdfpzRC T81A== X-Gm-Message-State: AOAM533V3HOacZEH6KNBTbB8BweVm1wfyxpkfWV2eshkLyZfcTXY4wXE gh54S6tCWdEirjjcTfKjm9HEqNpUIOg0h1Z8PPQ= X-Received: by 2002:a05:6830:1e03:: with SMTP id s3mr3606524otr.260.1614170782934; Wed, 24 Feb 2021 04:46:22 -0800 (PST) MIME-Version: 1.0 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> <20210222170420.000019a3.zbestahu@163.com> <20210224102435.00006325.zbestahu@gmail.com> In-Reply-To: <20210224102435.00006325.zbestahu@gmail.com> From: "Rafael J. Wysocki" Date: Wed, 24 Feb 2021 13:46:11 +0100 Message-ID: Subject: Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to busy CPU if need_freq_update is set To: Yue Hu Cc: "Rafael J. Wysocki" , Viresh Kumar , "Rafael J. Wysocki" , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Linux PM , Linux Kernel Mailing List , Yue Hu Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 24, 2021 at 3:24 AM Yue Hu wrote: > > On Mon, 22 Feb 2021 15:30:34 +0100 > "Rafael J. Wysocki" wrote: > > > On Mon, Feb 22, 2021 at 2:57 PM Yue Hu wrote: > > > > > > 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. > > > > That's because we realized that it was not always a good idea to skip > > the update even if next_f == sg_policy->next_freq. > > > > That's why CPUFREQ_NEED_UPDATE_LIMITS has been introduced and the > > current flow is a result of subsequent code rearrangements. > > ok, care about unnecessary(should be) behaviors(fast_switch_enabled and raw_spin_{lock,unlock}) > if need_freq_update is unset? > > If we care, i will send another patch (which is different from above change for busy CPU). Please send a patch and we'll see (this is how things go).