From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948501AbcBSRZS (ORCPT ); Fri, 19 Feb 2016 12:25:18 -0500 Received: from foss.arm.com ([217.140.101.70]:47609 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424899AbcBSRZP (ORCPT ); Fri, 19 Feb 2016 12:25:15 -0500 Date: Fri, 19 Feb 2016 17:26:04 +0000 From: Juri Lelli To: Srinivas Pandruvada Cc: "Rafael J. Wysocki" , Linux PM list , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , Viresh Kumar , Steve Muckle , Thomas Gleixner , "Rafael J. Wysocki" Subject: Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks Message-ID: <20160219172545.GA27380@e106622-lin> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1455900129.7375.231.camel@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Srinivas, On 19/02/16 08:42, Srinivas Pandruvada wrote: > On Fri, 2016-02-19 at 08:09 +0000, Juri Lelli wrote: > Hi Juri, > > >  > > Hi Rafael, > > > > On 18/02/16 21:22, Rafael J. Wysocki wrote: > > > On Mon, Feb 15, 2016 at 10:47 PM, Rafael J. Wysocki > > net> wrote: > > > > From: Rafael J. Wysocki > > > > > > > [...] > > > However, I still don't quite get why we want to introduce an > > interface > > for explicit passing of util and max if we are not using such > > parameters > > yet. Also, I couldn't find any indication of how such parameters will > > be > > used in the future. If what we need today is a periodic kick for > > cpufreq > > governors that need it, we should simply do how we already do for RT > > and > > DL, IMHO. Also because the places where the current hooks reside > > might > > not be the correct and useful one once we'll start using the > > utilization > > parameters. I could probably make a case for DL where we should place > > hooks in admission control path (or somewhere else when more > > sophisticated mechanisms we'll be in place) rather then in the > > periodic > > tick. > 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. > Thanks for your answer. What you are experimenting with looks really interesting and I'm certainly more than interested in looking at your findings and patches when they will hit the list. My point was more on what we can look at today, though. Without a clear understanding about how and where util and max will be used and from which scheduler paths such information should come from, it is a bit difficult to tell if the current interface and hooks are fine, IMHO. I'd suggest we leave this part to the discussion we will have once your proposal will be public; and to facilitate that we should remove those arguments from the current interface. Best, - Juri