From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753002AbcA0LMl (ORCPT ); Wed, 27 Jan 2016 06:12:41 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]:37748 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751298AbcA0LMi (ORCPT ); Wed, 27 Jan 2016 06:12:38 -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: Wed, 27 Jan 2016 16:42:22 +0530 From: Gautham R Shenoy To: Juri Lelli Cc: Gautham R Shenoy , Viresh Kumar , "Rafael J. Wysocki" , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Shilpasri G Bhat Subject: Re: [PATCH] cpufreq: Use list_is_last() to check last entry of the policy list Message-ID: <20160127111222.GA3755@in.ibm.com> Reply-To: ego@linux.vnet.ibm.com References: <1453715167-26165-1-git-send-email-ego@linux.vnet.ibm.com> <20160125095029.GE3183@vireshk> <20160125111824.GH10898@e106622-lin> <20160127060923.GB28238@in.ibm.com> <20160127101020.GL10898@e106622-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160127101020.GL10898@e106622-lin> User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16012711-0005-0000-0000-00001BCF589C Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 27, 2016 at 10:10:20AM +0000, Juri Lelli wrote: > On 27/01/16 11:39, Gautham R Shenoy wrote: > > On Mon, Jan 25, 2016 at 11:18:24AM +0000, Juri Lelli wrote: > > > Hi, > > > > > > On 25/01/16 15:20, Viresh Kumar wrote: > > > > On 25-01-16, 15:16, Gautham R. Shenoy wrote: > > > > > Currently next_policy() explicitly checks if a policy is the last > > > > > policy in the cpufreq_policy_list. Use the standard list_is_last > > > > > primitive instead. > > > > > > > > > > Cc: Viresh Kumar > > > > > Signed-off-by: Gautham R. Shenoy > > > > > --- > > > > > drivers/cpufreq/cpufreq.c | 6 +++--- > > > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > > > > > index 78b1e2f..b3059a3 100644 > > > > > --- a/drivers/cpufreq/cpufreq.c > > > > > +++ b/drivers/cpufreq/cpufreq.c > > > > > @@ -67,11 +67,11 @@ static struct cpufreq_policy *next_policy(struct cpufreq_policy *policy, > > > > > { > > > > > lockdep_assert_held(&cpufreq_driver_lock); > > > > > > Which branch is this patch based on? > > > > My bad! This is based on your branch git://linux-arm.org/linux-jl.git > > upstream/cpufreq_cleanups. I found this issue while reviewing your > > cleanup patches. > > > > No problem, and thanks for reviewing those! Any feedback? :) It's a timely patchset! Off late on POWER systems we've been observing a lot of jitters due to the on-demand worker thread periodically interrupting a running task to monitor (not necessarily change if the task!) frequency. We would very much like to see the frequency monitoring/change happen from an the timer-context instead of waking up a separate worker thread, something similar to CPUFREQ_DRIVER_FAST in sched_governor. However, that approach required a careful audit of all the locks that are currently taken in cpufreq core and this patch set is a good attempt in this direction. Barring the issues raised by Viresh with respect to the locking conventions around CPUFREQ_GOV_POLICY_EXIT, I didn't have any particular issues with it. > > Best, > > - Juri > -- Thanks and Regards gautham.