Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760333AbcCDWkh (ORCPT ); Fri, 4 Mar 2016 17:40:37 -0500 Received: from mail-lb0-f196.google.com ([209.85.217.196]:34190 "EHLO mail-lb0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758796AbcCDWkg (ORCPT ); Fri, 4 Mar 2016 17:40:36 -0500 MIME-Version: 1.0 In-Reply-To: References: <2495375.dFbdlAZmA6@vostro.rjw.lan> <2409306.qzzMXcm4dm@vostro.rjw.lan> <15684081.T4iOMUSHCY@vostro.rjw.lan> <56DA09B1.4010005@linaro.org> Date: Fri, 4 Mar 2016 23:40:34 +0100 X-Google-Sender-Auth: o8OJvo_6NqlvBTi03g0RAHUCxng 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" , 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: 2394 Lines: 57 On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki wrote: > On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle wrote: >> On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote: >>> +void cpufreq_driver_fast_switch(struct cpufreq_policy *policy, >>> + unsigned int target_freq, unsigned int relation) >>> +{ >>> + unsigned int freq; >>> + >>> + freq = cpufreq_driver->fast_switch(policy, target_freq, relation); >>> + if (freq != CPUFREQ_ENTRY_INVALID) { >>> + policy->cur = freq; >>> + trace_cpu_frequency(freq, smp_processor_id()); >>> + } >>> +} >> >> Even if there are platforms which may change the CPU frequency behind >> cpufreq's back, breaking the transition notifiers, I'm worried about the >> addition of an interface which itself breaks them. The platforms which >> do change CPU frequency on their own have probably evolved to live with >> or work around this behavior. As other platforms migrate to fast >> frequency switching they might be surprised when things don't work as >> advertised. > > Well, intel_pstate doesn't do notifies at all, so anything depending > on them is already broken when it is used. Let alone the hardware > P-states coordination mechanism (HWP) where the frequency is > controlled by the processor itself entirely. > > That said I see your point. > >> I'm not sure what the easiest way to deal with this is. I see the >> transition notifiers are the srcu type, which I understand to be >> blocking. Going through the tree and reworking everyone's callbacks and >> changing the type to atomic is obviously not realistic. > > Right. > >> How about modifying cpufreq_register_notifier to return an error if the >> driver has a fast_switch callback installed and an attempt to register a >> transition notifier is made? > > That sounds like a good idea. > > There also is the CPUFREQ_ASYNC_NOTIFICATION driver flag that in > principle might be used as a workaround, but I'm not sure how much > work that would require ATM. What I mean is that drivers using it are supposed to handle the notifications by calling cpufreq_freq_transition_begin(/end() by themselves, so theoretically there is a mechanism already in place for that. I guess what might be done would be to spawn a work item to carry out a notify when the frequency changes. Thanks, Rafael