Re: BUG_ON(irqs_disabled()) in cpufreq.c

Re: BUG_ON(irqs_disabled()) in cpufreq.c

[Viresh Kumar]

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:
>
> 1. 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

Re: BUG_ON(irqs_disabled()) in cpufreq.c

[Mike Turquette]

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:
> >
> > 1. 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

Re: BUG_ON(irqs_disabled()) in cpufreq.c

[Viresh Kumar]

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?

Re: BUG_ON(irqs_disabled()) in cpufreq.c

[Viresh Kumar]

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.