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;
Date:   Fri, 20 Nov 2020 14:49:04 +0530
From:   Viresh Kumar <viresh.kumar@linaro.org>
To:     Quentin Perret <qperret@google.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        dietmar.eggemann@arm.com, patrick.bellasi@matbug.net,
        lenb@kernel.org, linux-kernel@vger.kernel.org,
        valentin.schneider@arm.com, ionela.voinescu@arm.com
Subject: Re: [RFC] Documentation/scheduler/schedutil.txt
Message-ID: <20201120091904.6zvovj2yxjxtnq2x@vireshk-i7>
References: <20201120075527.GB2414@hirez.programming.kicks-ass.net>
 <20201120085653.GA3092@hirez.programming.kicks-ass.net>
 <20201120091356.GA2653684@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201120091356.GA2653684@google.com>
User-Agent: NeoMutt/20180716-391-311a52
Precedence: bulk

On 20-11-20, 09:13, Quentin Perret wrote:
> On Friday 20 Nov 2020 at 09:56:53 (+0100), Peter Zijlstra wrote:
> > On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote:
> > >  - In saturated scenarios task movement will cause some transient dips,
> > >    suppose we have a CPU saturated with 4 tasks, then when we migrate a task
> > >    to an idle CPU, the old CPU will have a 'running' value of 0.75 while the
> > >    new CPU will gain 0.25. This is inevitable and time progression will
> > >    correct this. XXX do we still guarantee f_max due to no idle-time?
> 
> The sugov_cpu_is_busy() logic should mitigate that, but looking at it
> again I just realized we don't apply it to the 'shared' update path. I
> can't recall why. Anybody?

t b7eaf1aab9f8bd2e49fceed77ebc66c1b5800718
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Wed Mar 22 00:08:50 2017 +0100

    cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely
   
   [skip]
    
    This is unlikely to be an issue on systems where cpufreq policies are
    shared between multiple CPUs, because in those cases the policy
    utilization is computed as the maximum of the CPU utilization values
    over the whole policy and if that turns out to be low, reducing the
    frequency for the policy most likely is a good idea anyway.  On
    systems with one CPU per policy, however, it may affect performance
    adversely and even lead to increased energy consumption in some cases.
    
    On those systems it may be addressed by taking another utilization
    metric into consideration, like whether or not the CPU whose
    frequency is about to be reduced has been idle recently, because if
    that's not the case, the CPU is likely to be busy in the near future
    and its frequency should not be reduced.

-- 
viresh