From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755987AbcBIKBl (ORCPT ); Tue, 9 Feb 2016 05:01:41 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:54519 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753132AbcBIKBh (ORCPT ); Tue, 9 Feb 2016 05:01:37 -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: Tue, 9 Feb 2016 15:31:03 +0530 From: Gautham R Shenoy To: "Rafael J. Wysocki" Cc: Linux PM list , Linux Kernel Mailing List , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Juri Lelli , Steve Muckle , Thomas Gleixner Subject: Re: [PATCH 3/3 v5] cpufreq: governor: Replace timers with utilization update callbacks Message-ID: <20160209100103.GB5726@in.ibm.com> Reply-To: ego@linux.vnet.ibm.com References: <3071836.JbNxX8hU6x@vostro.rjw.lan> <1486401.1RcnnVKZNP@vostro.rjw.lan> <2848076.UWJmIl2O1K@vostro.rjw.lan> <2448026.UXsVxjJmrX@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2448026.UXsVxjJmrX@vostro.rjw.lan> User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16020910-8236-0000-0000-000015EFAD41 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Rafael, On Sun, Feb 07, 2016 at 03:50:31PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Instead of using a per-CPU deferrable timer for queuing up governor > work items, register a utilization update callback that will be > invoked from the scheduler on utilization changes. > > The sampling rate is still the same as what was used for the > deferrable timers and the added irq_work overhead should be offset by > the eliminated timers overhead, so in theory the functional impact of > this patch should not be significant. I tested this patch series (including v5 of PATCH 3) on POWER with Viresh's CPUFreq test suite. I didn't see any issues with the patchset except for a lockdep splat involving "s_active" and "od_dbs_cdata.mutex", which was also observed on 4.5-rc3 and which was fixed by Viresh's recent patches. With a kernbench run, there were no regression when compared to 4.5-rc3. FWIW, Tested-by: Gautham R. Shenoy > > Thanks, > Rafael -- Thanks and Regards gautham.