Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753914AbdGJMyU (ORCPT ); Mon, 10 Jul 2017 08:54:20 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:61671 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753245AbdGJMyT (ORCPT ); Mon, 10 Jul 2017 08:54:19 -0400 From: "Rafael J. Wysocki" To: Viresh Kumar Cc: Dietmar Eggemann , Peter Zijlstra , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM , Russell King - ARM Linux , Greg Kroah-Hartman , Russell King , Catalin Marinas , Will Deacon , Juri Lelli , Vincent Guittot , Morten Rasmussen Subject: Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support Date: Mon, 10 Jul 2017 14:46:38 +0200 Message-ID: <4673356.gkeX7KYvlb@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.12.0-rc1+; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170710065443.GG2928@vireshk-i7> References: <20170706094948.8779-1-dietmar.eggemann@arm.com> <12829054.TWIodSo4bb@aspire.rjw.lan> <20170710065443.GG2928@vireshk-i7> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 30 On Monday, July 10, 2017 12:24:43 PM Viresh Kumar wrote: > On 08-07-17, 14:09, Rafael J. Wysocki wrote: > > I'm sort of wondering how many is "a lot" really. For instance, do you really > > want all of the existing ARM platforms to use the new stuff even though > > it may regress things there in principle? > > That's a valid question and we must (maybe we already have) have a policy for > such changes. I don't think it is a matter of policy, as it tends to vary from case to case. What really matters is the reason to make the changes in this particular case. If the reason if to help new systems to work better in the first place and the old ones are affected just by the way, it may be better to avoid affecting them. On the other hand, if the reason is to improve things for all the new and old systems altogether, then sure let's do it this way. > I thought that such changes (which are so closely bound to the > scheduler) must be at least done at the architecture level and not really at > platform level. And so doing it widely (like done in this patch) maybe the right > thing to do. This particular change is about a new feature, so making it in the core is OK in two cases IMO: (a) when you actively want everyone to be affected by it and (b) when the effect of it on the old systems should not be noticeable. Thanks, Rafael