Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760597AbcCEASs (ORCPT ); Fri, 4 Mar 2016 19:18:48 -0500 Received: from mail-lb0-f193.google.com ([209.85.217.193]:33748 "EHLO mail-lb0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760128AbcCEASo (ORCPT ); Fri, 4 Mar 2016 19:18:44 -0500 MIME-Version: 1.0 In-Reply-To: <56DA20C0.1070803@linaro.org> References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <2409306.qzzMXcm4dm@vostro.rjw.lan> <15684081.T4iOMUSHCY@vostro.rjw.lan> <56DA09B1.4010005@linaro.org> <56DA20C0.1070803@linaro.org> Date: Sat, 5 Mar 2016 01:18:41 +0100 X-Google-Sender-Auth: Bp71cRaM1EDvzFxQtos8Xcx1gk4 Message-ID: Subject: Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching From: "Rafael J. Wysocki" To: Steve Muckle Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Linux PM list , Juri Lelli , ACPI Devel Maling List , Linux Kernel Mailing List , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Vincent Guittot , Michael Turquette , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2587 Lines: 57 On Sat, Mar 5, 2016 at 12:56 AM, Steve Muckle wrote: > On 03/04/2016 03:18 PM, Rafael J. Wysocki wrote: >> In fact, the mechanism may be relatively simple if I'm not mistaken. >> >> In the "fast switch" case, the governor may spawn a work item that >> will just execute cpufreq_get() on policy->cpu. That will notice that >> policy->cur is different from the real current frequency and will >> re-adjust. >> >> Of course, cpufreq_driver_fast_switch() will need to be modified so it >> doesn't update policy->cur then perhaps with a comment that the >> governor using it will be responsible for that. >> >> And the governor will need to avoid spawning that work item too often >> (basically, if one has been spawned already and hasn't completed, no >> need to spawn a new one, and maybe rate-limit it?), but all that looks >> reasonably straightforward. > > It is another option though definitely a compromise. The semantics seem > different since you'd potentially have multiple freq changes before a > single notifier went through, so stuff might still break. Here I'm not worried. That's basically equivalent to someone doing a "get" and seeing an unexpected frequency in the driver output which is covered already and things need to cope with it or they are just really broken. > The fast path would also be more expensive given the workqueue activity that could > translate into additional task wakeups. That's a valid concern, so maybe there can be a driver flag to indicate that this has to be done if ->fast_switch is in use? Or something like fast_switch_notify_rate that will tell the governor how often to notify things about transitions if ->fast_switch is in use with either 0 or all ones meaning "never"? That might be a policy property even, so the driver may set this depending on what platform it is used on. > Honestly I wonder if it's better to just try the "no notifiers with fast > drivers" approach to start. The notifiers could always be added if > platform owners complain that they absolutely require them. Well, I'm not sure what happens if we start to fail notifier registrations. It may not be a well tested error code path. :-) Besides, there is the problem with registering notifiers before the driver and I don't think we can fail driver registration if notifiers have already been registered. We may not be able to register a "fast" driver at all in that case. But that whole thing is your worry, not mine. :-) Had I been worrying about that, I would have added some bandaid for that to the patches. Thanks, Rafael