More lists cc'd
On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino giardino@ece.gatech.edu wrote:
Hi,
I hope this is the right spot to ask this.
Is there any way to change the cpu frequency using the cpufreq driver from within an hrtimer callback function? I encounter a kernel panic at cpufreq.c line 255 (260 in 3.9.5)
void __cpufreq_notify_transition(struct cpufreq_policy *policy, 253 struct cpufreq_freqs *freqs, unsigned int state) 254 { 255 BUG_ON(irqs_disabled());
I'm assuming this is due to the cpufreq_notify_transition needs interrupts to notify? Is there a way around this? It appears that acpi-cpufreq.c is calling the notifier both before and after the transition (CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE).
Are there any frequency change functions that can operate without interrupts?
The background is this:
For the past few days I have been trying to get to the bottom of a problem involving a nonSMP governor I have written. The goal of this governor is to change the frequency on a predefined schedule (in the ms scale). The basic breakdown is this:
- The external scheduler computes schedules and then passes them to
the governor (with much code appropriated from the userspace governor) via an exported function. 2. The governor sets the frequency, then sets a timer to call the next frequency change when it goes off
In order to do this, I was using hrtimers. These timer's callback functions run with interrupts disabled.
Michael Giardino giardino@ece.gatech.edu
michael.giardino@gmail.com
To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting Viresh Kumar (2013-08-01 22:02:37)
More lists cc'd
On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino giardino@ece.gatech.edu wrote:
Hi,
I hope this is the right spot to ask this.
Is there any way to change the cpu frequency using the cpufreq driver from within an hrtimer callback function? I encounter a kernel panic at cpufreq.c line 255 (260 in 3.9.5)
It is not just about the notifiers.
Performing a clock rate change and voltage regulator transition (DVFS) is not a short operation on many ARM platforms. Relocking a PLL and waiting for a regulator to step and stabilize can take well over 100 milliseconds and some of those functions might sleep.
Some ARM platform do not manage this directly and talk to a power management micro controller, so we could probably do that with interrupts disabled if it's just a matter of writing to some memory-mapped registers.
I don't know how Intel does it with ACPI but I assume that they don't block waiting for things to happen based on a recent G+ post I read[1]. I have even less of a clue how the other architectures out there do it.
So the question in general is whether we should assume that we may sleep or block during a CPU frequency scaling operation. The short answer seems to be "yes" since some platforms need this today.
Perhaps CPUfreq could allow for differentiating between platforms that need to sleep/block and those that do not?
Regards, Mike
[1] https://plus.google.com/114657443111661859546/posts/dLn9T4ehywL
void __cpufreq_notify_transition(struct cpufreq_policy *policy, 253 struct cpufreq_freqs *freqs, unsigned int state) 254 { 255 BUG_ON(irqs_disabled());
I'm assuming this is due to the cpufreq_notify_transition needs interrupts to notify? Is there a way around this? It appears that acpi-cpufreq.c is calling the notifier both before and after the transition (CPUFREQ_PRECHANGE and CPUFREQ_POSTCHANGE).
Are there any frequency change functions that can operate without interrupts?
The background is this:
For the past few days I have been trying to get to the bottom of a problem involving a nonSMP governor I have written. The goal of this governor is to change the frequency on a predefined schedule (in the ms scale). The basic breakdown is this:
- The external scheduler computes schedules and then passes them to
the governor (with much code appropriated from the userspace governor) via an exported function. 2. The governor sets the frequency, then sets a timer to call the next frequency change when it goes off
In order to do this, I was using hrtimers. These timer's callback functions run with interrupts disabled.
Michael Giardino giardino@ece.gatech.edu
michael.giardino@gmail.com
To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
On 2 August 2013 12:08, Mike Turquette mturquette@linaro.org wrote:
Quoting Viresh Kumar (2013-08-01 22:02:37)
More lists cc'd
On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino giardino@ece.gatech.edu wrote:
Hi,
I hope this is the right spot to ask this.
Is there any way to change the cpu frequency using the cpufreq driver from within an hrtimer callback function? I encounter a kernel panic at cpufreq.c line 255 (260 in 3.9.5)
It is not just about the notifiers.
Performing a clock rate change and voltage regulator transition (DVFS) is not a short operation on many ARM platforms. Relocking a PLL and waiting for a regulator to step and stabilize can take well over 100 milliseconds and some of those functions might sleep.
BTW, The routine in question doesn't change frequency by itself. But the caller of this routine will change clk just after/before calling this routine.
I don't really know why this code was initially written there, but I don't think we should add such a BUG() or WARN() to satisfy performance of a system.
They should be used only when it is not possible to execute the notifier when interrupts are disabled.
You have any clue why this code was placed here?
Hi,
On 2 August 2013 09:42, Viresh Kumar viresh.kumar@linaro.org wrote:
On 2 August 2013 12:08, Mike Turquette mturquette@linaro.org wrote:
Quoting Viresh Kumar (2013-08-01 22:02:37)
More lists cc'd
On Thu, Aug 1, 2013 at 6:08 PM, Michael Giardino giardino@ece.gatech.edu wrote:
Hi,
I hope this is the right spot to ask this.
Is there any way to change the cpu frequency using the cpufreq driver from within an hrtimer callback function? I encounter a kernel panic at cpufreq.c line 255 (260 in 3.9.5)
It is not just about the notifiers.
Performing a clock rate change and voltage regulator transition (DVFS) is not a short operation on many ARM platforms. Relocking a PLL and waiting for a regulator to step and stabilize can take well over 100 milliseconds and some of those functions might sleep.
BTW, The routine in question doesn't change frequency by itself. But the caller of this routine will change clk just after/before calling this routine.
I don't really know why this code was initially written there, but I don't think we should add such a BUG() or WARN() to satisfy performance of a system.
They should be used only when it is not possible to execute the notifier when interrupts are disabled.
You have any clue why this code was placed here?
Like Mike said, the reason is the assumption that DVFS actions may want to sleep. While that may not be true for you, the governor you are working on might get used on a platform where these actions do sleep. Therefore, regardless of the actual situation, these functions are always assumed to need a non-interrupt context.
One workaround you'll have to consider is similar to "top half/bottom half" interrupt handler setup. Have your hrtimer handler wake up a work thread/task which will perform the actual work and is able to sleep. The drawback is of course that your timing is now less precise as there is no guarantee that the non-interrupt code will get scheduled immediately and it is easier to have race conditions in such an arrangement.
Tuukka
On 2 August 2013 14:29, Tuukka Tikkanen tuukka.tikkanen@linaro.org wrote:
Like Mike said, the reason is the assumption that DVFS actions may want to sleep. While that may not be true for you, the governor you are working on might get used on a platform where these actions do sleep. Therefore, regardless of the actual situation, these functions are always assumed to need a non-interrupt context.
I have the same answer to this as what I wrote in my last mail.
BTW, The routine in question doesn't change frequency by itself. But the caller of this routine will change clk just after/before calling this routine.
And so, this routine doesn't need interrupts to be disabled.
linaro-kernel@lists.linaro.org
-
Mike Turquette -
Tuukka Tikkanen -
Viresh Kumar