From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758000AbcBDLbT (ORCPT ); Thu, 4 Feb 2016 06:31:19 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:53303 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753574AbcBDLbP (ORCPT ); Thu, 4 Feb 2016 06:31:15 -0500 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: ego@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;linux-pm@vger.kernel.org Date: Thu, 4 Feb 2016 17:01:02 +0530 From: Gautham R Shenoy To: Viresh Kumar Cc: ego@linux.vnet.ibm.com, "Rafael J. Wysocki" , Linux PM list , Linux Kernel Mailing List , Srinivas Pandruvada , Juri Lelli , Steve Muckle , Saravana Kannan Subject: Re: [PATCH 3/11] cpufreq: governor: Use common global_dbs_data pointer Message-ID: <20160204113102.GA17371@in.ibm.com> Reply-To: ego@linux.vnet.ibm.com References: <3705929.bslqXH980s@vostro.rjw.lan> <1876466.AY9fn15fDn@vostro.rjw.lan> <20160204053614.GV3469@vireshk> <20160204082538.GB3469@vireshk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160204082538.GB3469@vireshk> User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16020411-8236-0000-0000-000015CDC680 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Viresh, On Thu, Feb 04, 2016 at 01:55:38PM +0530, Viresh Kumar wrote: > On 04-02-16, 13:44, Gautham R Shenoy wrote: > > In a a two policy system, to run ondemand on one and conservative on the other, > >  won't the driver have CPUFREQ_HAVE_GOVERNOR_PER_POLICY set?   > > No. > > CPUFREQ_HAVE_GOVERNOR_PER_POLICY is not about the facility of using > separate governor-type for each policy, that is always available to > the user. > > CPUFREQ_HAVE_GOVERNOR_PER_POLICY was initially added for platforms > with different type of CPUs on the same chip, though others can > benefit from it as well. > > For example, on a 4 core ARM big LITTLE platform, we will have: > - 2 A7 (low performance/low power) > - 2 A15 (high performance/high power) > > The A7's share a policy and A15's share another one. > > Without CPUFREQ_HAVE_GOVERNOR_PER_POLICY, if ondemand is selected for > both the policies, the we used to get a single directory (and a set of > tunables) at /sys/devices/system/cpu/cpufreq/ondemand/ . > > That used to force us to use same tunables, like sampling rate, etc > for both the policies. > > But because the CPUs were so different, we really wanted independent > control. > > So, we designed CPUFREQ_HAVE_GOVERNOR_PER_POLICY, so that in such > cases, each policy will have a set of tunables for the same governor > type. > > Hope that makes it clear. Yes it does! Thank you for the explanation. So, the CPUFREQ_HAVE_GOVERNOR_PER_POLICY is really CPUFREQ_HAVE_GOVERNOR_TUNERS_PER_POLICY. Can we change the name to reflect the intent? > > If the below questionnaire is still valid, please let me know :) No, it is no longer valid! > > viresh -- Thanks and Regards gautham.