From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992693AbcBSR2a (ORCPT ); Fri, 19 Feb 2016 12:28:30 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:38609 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425721AbcBSR22 (ORCPT ); Fri, 19 Feb 2016 12:28:28 -0500 Subject: Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks To: Srinivas Pandruvada , Juri Lelli , "Rafael J. Wysocki" References: <3071836.JbNxX8hU6x@vostro.rjw.lan> <2044559.7ypXocW9OZ@vostro.rjw.lan> <3499355.2JlaSruvOa@vostro.rjw.lan> <16016177.YFqb4gVNBo@vostro.rjw.lan> <20160219080917.GE22643@pablo> <1455900129.7375.231.camel@linux.intel.com> Cc: Linux PM list , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , Viresh Kumar , Thomas Gleixner , "Rafael J. Wysocki" From: Steve Muckle X-Enigmail-Draft-Status: N1110 Message-ID: <56C750B7.6090701@linaro.org> Date: Fri, 19 Feb 2016 09:28:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1455900129.7375.231.camel@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/19/2016 08:42 AM, Srinivas Pandruvada wrote: > We did experiments using util/max in intel_pstate. For some benchmarks > there were regression of 4 to 5%, for some benchmarks it performed at > par with getting utilization from the processor. Further optimization > in the algorithm is possible and still in progress. Idea is that we can > change P-State fast enough and be more reactive. Once I have good data, > I will send to this list. The algorithm can be part of the cpufreq > governor too. There has been a lot of work in the area of scheduler-driven CPU frequency selection by Linaro and ARM as well. It was posted most recently a couple months ago: http://thread.gmane.org/gmane.linux.power-management.general/69176 It was also posted as part of the energy-aware scheduling series last July. There's a new RFC series forthcoming which I had hoped (and failed) to post prior to my business travel this week; it should be out next week. It will address the feedback received thus far along with locking and other things. The scheduler hooks for utilization-based cpufreq operation deserve a lot more debate I think. They could quite possibly have different requirements than hooks which are chosen just to guarantee periodic callbacks into sampling-based governors. For my part I think it would be best if the util/max parameters are omitted until it's clear whether these same hooks can be effectively used for architecture agnostic scheduler-guided (capacity driven) CPU frequency support. My upcoming RFC will provide another opportunity to debate the hooks as well as how scheduler-guided CPU frequency should be structured. thanks, Steve