From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757253AbcBWD6v (ORCPT ); Mon, 22 Feb 2016 22:58:51 -0500 Received: from mail-pa0-f41.google.com ([209.85.220.41]:36127 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757023AbcBWD6t (ORCPT ); Mon, 22 Feb 2016 22:58:49 -0500 Subject: Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks To: "Rafael J. Wysocki" References: <3071836.JbNxX8hU6x@vostro.rjw.lan> <1455900129.7375.231.camel@linux.intel.com> <56C750B7.6090701@linaro.org> <1797575.PjqbkdCLyN@vostro.rjw.lan> Cc: Srinivas Pandruvada , Juri Lelli , "Rafael J. Wysocki" , Linux PM list , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List , Viresh Kumar , Thomas Gleixner From: Steve Muckle X-Enigmail-Draft-Status: N1110 Message-ID: <56CBD8F7.3090502@linaro.org> Date: Mon, 22 Feb 2016 19:58:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1797575.PjqbkdCLyN@vostro.rjw.lan> 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 02:35 PM, Rafael J. Wysocki wrote: >> 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. > > Yes, they could. > > The point here, though, is that even the sampling-based governors may > benefit from using the numbers provided by the scheduler instead of trying > to come up with analogous numbers themselves. It seems premature to me to merge supporting infrastructure (the utilization hooks) before we have changes, be it modifications to the sampling based governors to use utilization or a scheduler-guided governor, which are well tested and proven to yield reasonable performance and power across various platforms and workloads. Perhaps I'm a pessimist but I think it's going to be a challenge to get utilization-based cpufreq on par, and I think getting the hooks right will be part of that challenge. >> For my part I think it would be best if the util/max parameters are >> omitted > > OK, so please see the patch I've just sent to Juri: > > https://patchwork.kernel.org/patch/8364621/ Looked good to me. thanks, Steve