Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 18 Jul 2019 15:58:15 +0530
From:   Viresh Kumar <viresh.kumar@linaro.org>
To:     Doug Smythies <doug.smythies@gmail.com>
Cc:     rjw@rjwysocki.net, joel@joelfernandes.org,
        linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
        dsmythies@telus.net
Subject: Re: [PATCH] Revert "cpufreq: schedutil: Don't set next_freq to
 UINT_MAX"
Message-ID: <20190718102815.utl3hanfc7fpf2i6@vireshk-i7>
References: <1563431200-3042-1-git-send-email-dsmythies@telus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1563431200-3042-1-git-send-email-dsmythies@telus.net>
User-Agent: NeoMutt/20180716-391-311a52
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 17-07-19, 23:26, Doug Smythies wrote:
> This reverts commit ecd2884291261e3fddbc7651ee11a20d596bb514.
> 
> The commit caused a regression whereby reducing the maximum
> CPU clock frequency is ineffective while busy, and the CPU
> clock remains unchanged. Once the system has experienced
> some idle time, the new limit is implemented.

Can you explain why this patch caused that issue ? I am sorry but I couldn't
understand it from your email. How are we trying to reduce the frequency? Is
clk_set_rate() getting called with that finally and not working ?

> A consequence is that any thermal throttling monitoring
> and control based on max freq limits fail to respond
> in a timely manor, if at all, to a thermal temperature
> trip on a busy system.

-- 
viresh