Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752653AbcKHIcc (ORCPT ); Tue, 8 Nov 2016 03:32:32 -0500 Received: from mail-qt0-f176.google.com ([209.85.216.176]:33728 "EHLO mail-qt0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752220AbcKHIca (ORCPT ); Tue, 8 Nov 2016 03:32:30 -0500 MIME-Version: 1.0 In-Reply-To: <076fb177-9cb3-4534-aadb-ebc2190d0751@email.android.com> References: <076fb177-9cb3-4534-aadb-ebc2190d0751@email.android.com> From: Viresh Kumar Date: Tue, 8 Nov 2016 14:02:29 +0530 Message-ID: Subject: Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred To: Stratos Karafotis Cc: "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , "Rafael J. Wysocki" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 889 Lines: 27 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. -- viresh