Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753123AbcKHTZX (ORCPT ); Tue, 8 Nov 2016 14:25:23 -0500 Received: from mail.semaphore.gr ([138.201.185.188]:53294 "EHLO mail.semaphore.gr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752189AbcKHTZW (ORCPT ); Tue, 8 Nov 2016 14:25:22 -0500 Subject: Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred To: Viresh Kumar References: <076fb177-9cb3-4534-aadb-ebc2190d0751@email.android.com> Cc: "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , "Rafael J. Wysocki" From: Stratos Karafotis Message-ID: <5ea3831e-7743-d39f-1f02-96c915cc757e@semaphore.gr> Date: Tue, 8 Nov 2016 21:25:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1848 Lines: 47 On 08/11/2016 10:32 πμ, Viresh Kumar wrote: > On 8 November 2016 at 12:49, Stratos Karafotis wrote: >> I think we shouldn't. That's why the patch first decreases the frequency >> by n freq steps (where n the number of deferred periods). >> Then the normal processing takes place. > > The problem that I see is that the new algorithm will reduce the > frequency even if we are > on a ramp up phase. > > For example consider this case: > > - We have a special load running, that runs in bursts. i.e. runs for > some time, lets the CPU idle > then and then again runs. > > - To run the load properly, we need to ramp up the frequency > > - But the new algorithm can make the frequency stagnant in this case. > i.e. because of the idle > period you may want to decrease the frequency by delta A and then the > regular algorithm may > want to increase it by same delta A. > > That's why I was asking to adopt this only in the ramp down path. > But this is the supposed behaviour of conservative governor. We want the CPU to increase the frequency in steps. The patch just resets the frequency to a lower frequency in case of idle. For argument's sake, let's assume that the governor timer is never deferred and runs every sampling period even on completely idle CPU. And let's assume, for example, a burst load that runs every 100ms for 20ms. The default sampling rate is also 20ms. What would conservative do in case of that burst load? It would increase the frequency by one freq step after 20ms and then it would decrease the frequency 4 times by one frequency step. Most probably on the next burst load, the CPU will run on min frequency. I agree that maybe this is not ideal for performance but maybe this is how we want conservative governor to work (lazily increase and decrease frequency). Regards, Stratos