From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753253AbcA0ByW (ORCPT ); Tue, 26 Jan 2016 20:54:22 -0500 Received: from mail-pa0-f52.google.com ([209.85.220.52]:34959 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753171AbcA0ByQ (ORCPT ); Tue, 26 Jan 2016 20:54:16 -0500 Subject: Re: sched-freq locking To: "Rafael J. Wysocki" , Juri Lelli References: <56984C30.8040402@linaro.org> <5334719.Agh48cz3NL@vostro.rjw.lan> <20160121104958.GX8573@e106622-lin> <2223980.TtBr1NiYl7@vostro.rjw.lan> Cc: Michael Turquette , Vincent Guittot , Patrick Bellasi , Morten Rasmussen , Dietmar Eggemann , Viresh Kumar , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , Peter Zijlstra , Javi Merino , Punit Agrawal From: Steve Muckle X-Enigmail-Draft-Status: N1110 Message-ID: <56A82345.8080709@linaro.org> Date: Tue, 26 Jan 2016 17:54:13 -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: <2223980.TtBr1NiYl7@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 01/21/2016 05:21 PM, Rafael J. Wysocki wrote: > On Thursday, January 21, 2016 10:49:58 AM Juri Lelli wrote: >> [+Punit, Javi] >> >> Hi Rafael, >> >> On 21/01/16 02:46, Rafael J. Wysocki wrote: >>> On Wednesday, January 20, 2016 05:39:14 PM Steve Muckle wrote: >>>> On 01/20/2016 05:22 PM, Rafael J. Wysocki wrote: >>>>> One comment here (which may be a bit off in which case please ignore it). >>>>> >>>>> You seem to be thinking that sched-freq needs to be a cpufreq governor >>>>> and thus be handled in the same way as ondemand, for example. >>>> >>>> That's true, I hadn't really given much thought to the alternative you >>>> mention below. >>>> >>>>> >>>>> However, this doesn't have to be the case in principle. For example, >>>>> if we have a special driver callback specifically to work with sched-freq, >>>>> it may just use that callback and bypass (almost) all of the usual >>>>> cpufreq mechanics. This way you may avoid worrying about the governor >>>>> locking and related ugliness entirely. >>>> >>>> That sounds good but I'm worried about other consequences of taking >>>> cpufreq out of the loop. For example wouldn't we need a new way for >>>> something like thermal to set frequency limits? >>> >>> I don't know from the top of my head, but that's at least worth investigating. >>> >> >> Yes, that's an interesting alternative that we have to think through. >> >>> Maybe we can keep the interface for those things unchanged, but handle it >>> differently under the hood? >>> >> >> Let me see if I understand what you are proposing :). If we don't want >> to duplicate too many things, maybe it is still feasible to just use >> existing cpufreq mechanics to handle hotplug, sysfs, thermal, etc. (with >> possibly minor modifications to be notified of events) and only create a >> new method to ask the driver for frequency changes, since we will have >> replicated policy and freq_table information inside sched-freq. Is that >> what you were also thinking of by saying "bypass (almost) all the usual >> cpufreq mechanics"? :) > > Yes, it is. I've been working on the locking in schedfreq (governor) and believe it is now functionally correct. It'll get sent out in another RFC soon. Having wrestled with that locking a bit I can appreciate the value of potentially deprecating some or all of the cpufreq core. I'm also fearful though of making the current task (creating a scheduler-based CPU frequency scaling algorithm) more complex than it is already. For that reason my preference would be to get the thing to a viable state as a governor first, assuming that's possible, and then take on restructuring to eliminate/deprecate unnecessary infrastructure. Does this seem reasonable? thanks, Steve