Thread (155 messages) 155 messages, 12 authors, 2016-03-18

Re: [PATCH v2 6/10] cpufreq: Support for fast frequency switching

From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2016-03-04 22:40:37
Also in: linux-acpi, lkml

On Fri, Mar 4, 2016 at 11:32 PM, Rafael J. Wysocki [off-list ref] wrote:
On Fri, Mar 4, 2016 at 11:18 PM, Steve Muckle [off-list ref] wrote:
quoted
On 03/03/2016 07:07 PM, Rafael J. Wysocki wrote:
quoted
+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.
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help