gmane.linux.kernel.cpufreq

Clarification on the DVFS capabilities

karthik vm — 2013-05-21T16:18:40

Hi,

I have few doubts on the DVFS capabilities of my intel Core2Duo
processor (T5750) which has 2 cores (no hyperthreading) and has
Enhanced Intel Speed Step Technology (EIST). When I run the
"cpufreq-info" command in Ubuntu Linux I get the result that: "CPUs
which run at the same hardware frequency: 0 1". Hence I assumed that
both the CPUs will increase and decrease the frequency in a
synchronous fashion.

But when I tried to verify it by using the below command:

$ watch -n 0.1 grep \"cpu MHz\" /proc/cpuinfo

Here I see that each core is varying the frequency individually
contrary to the cpufreq-info commands output that both run at the same
hardware frequency. Hence can anyone comment on this behavior?

Regards,
karthik
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Michael Wang — 2013-05-21T07:58:39

Well, they share the same cpu_down() I suppose...


IMHO, the problem seems mostly like the wrong usage of policy->cpus,
it's providing the right info, but just at that time, we don't need
worry about work on offlined cpu if we don't allow cpu disappear.

Your approach could be good respect to performance, but if we could
prove that policy->cpus is correct firstly, than we could fix the
problem without any concern, don't we?


I'm fine if the problem get solved, that means your box doesn't show
WARN any more :)

Regards,
Michael Wang


--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Borislav Petkov — 2013-05-21T07:21:40

Strictly speaking you're correct but I don't do any hotplug besides the
one-time thing which is part of halting the box.


Yes, that's my impression too - at the point we do gov_queue_work,
policy->cpus already contains offline cpus.


Yes, but I don't want to schedule work on an offlined cpu and that is
ensured here.


Sure, feel free to get a box, enable NO_HZ_FULL and do all the
experimentations you desire. I surely cannot be the only one who
triggers this.

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Michael Wang — 2013-05-21T02:37:24

[snip]

like this:

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 443442d..8ed8b35 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
< at >< at > -26,6 +26,7 < at >< at >
 #include <linux/tick.h>
 #include <linux/types.h>
 #include <linux/workqueue.h>
+#include <linux/cpu.h>
 
 #include "cpufreq_governor.h"
 
< at >< at > -169,6 +170,9 < at >< at > static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
 {
        struct cpu_dbs_common_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
 
+       if (WARN_ON(!cpu_online(cpu)))
+               return;
+
        mod_delayed_work_on(cpu, system_wq, &cdbs->work, delay);
 }
 
< at >< at > -180,8 +184,10 < at >< at > void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
        if (!all_cpus) {
                __gov_queue_work(smp_processor_id(), dbs_data, delay);
        } else {
+               get_online_cpus();
                for_each_cpu(i, policy->cpus)
                        __gov_queue_work(i,

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Michael Wang — 2013-05-21T02:20:51

This is not enough to prove that policy->cpus is wrong, the cpu could be
online when get from policy->cpus, but offline when checked here, since
hotplug is able to happen during the period.


I don't get it...

get_online_cpus() is just stop hotplug happen after it was invoked, so
unless policy->cpus is really wrong, otherwise all the cpu it masked
won't go offline any more.


This protect nothing...before we go here, the cpu could already offline,
nothing changed...

If you really want to confirm the policy->cpus was wrong, the way should
be apply the fix I suggested, than check online in here.

If hotplug could not happen but still get an offline cpu from
policy->cpus, than we could say it's wrong, otherwise we proved nothing...

Regards,
Michael Wang


--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 58541] [pandaboard] cpu frequency limitation

2013-05-20T20:58:16

https://bugzilla.kernel.org/show_bug.cgi?id=58541





--- Comment #4 from Tobias Jakobi <liquid.acid< at >gmx.net>  2013-05-20 20:58:16 ---
Thanks for the update. It's good to know that you guys are working on it!

[Bug 58541] [pandaboard] cpu frequency limitation

2013-05-20T19:49:59

https://bugzilla.kernel.org/show_bug.cgi?id=58541





--- Comment #3 from Nishanth Menon <nm< at >ti.com>  2013-05-20 19:49:58 ---
I think this should be assigned to linux-omap instead of cpufreq btw.

[Bug 58541] [pandaboard] cpu frequency limitation

2013-05-20T19:48:17

https://bugzilla.kernel.org/show_bug.cgi?id=58541


Nishanth Menon <nm< at >ti.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nm< at >ti.com




--- Comment #2 from Nishanth Menon <nm< at >ti.com>  2013-05-20 19:48:16 ---
This is correct - *ONLY* 920MHz will be supported by default without AVS Class
1.5, Adaptive Body Bias(ABB) support enabled. ABB and AVS class 1.5 is
mandatory for frequencies 1.2GHz and 1.5GHz to be enabled.

For PandaBoard ES, we also have additional constraint. MPU voltage is supplied
by TPS62391 PMIC chip which can only be controlled from I2C_SR.

we DONOT have any form of support for pmic control over i2c_sr.

Current status:
a) ABB support - currently blocked due to lack of clock node support in OF.
   i) ABB driver support and DTS conversion:
http://marc.info/?l=linux-omap&m=136751559523901&w=2
   ii) Clock node support preventing this from being merge

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Borislav Petkov — 2013-05-20T15:08:09

No, not yet. Pretty busy ATM. Btw, you could try reproducing it too, in
the meantime - simply enable

CONFIG_NO_HZ_COMMON=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
CONFIG_NO_HZ=y
CONFIG_RCU_FAST_NO_HZ=y

and halt the box. I don't know whether !x86 boxen support NO_HZ_FULL yet
though.

[Bug 58541] [pandaboard] cpu frequency limitation

2013-05-20T14:33:09

https://bugzilla.kernel.org/show_bug.cgi?id=58541





--- Comment #1 from Tobias Jakobi <liquid.acid< at >gmx.net>  2013-05-20 14:33:08 ---
Created an attachment (id=102061)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=102061)
kernel config

[Bug 58541] New: [pandaboard] cpu frequency limitation

2013-05-20T14:31:25

https://bugzilla.kernel.org/show_bug.cgi?id=58541

           Summary: [pandaboard] cpu frequency limitation
           Product: Power Management
           Version: 2.5
    Kernel Version: 3.9.3
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: cpufreq
        AssignedTo: cpufreq< at >vger.kernel.org
        ReportedBy: liquid.acid< at >gmx.net
        Regression: No


Created an attachment (id=102051)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=102051)
dmesg output after boot

Hello,

the ARMv7 in the Pandaboard ES (OMAP4460) should support a maximum frequency of
around 1.2GHz.

However it looks like that it's currently limited to 920MHz.

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:
350000 700000 920000

Even worse:

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 
699977

Greets,
Tobias

Re: [PATCH 07/18] cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq

Kukjin Kim — 2013-05-20T13:47:59

[...]


Yeah, already done in my local and you can see it in my public tree in a 
couple of hours :-)

Thanks.

- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Viresh Kumar — 2013-05-20T13:43:08

Hmm, so for sure there is some locking issue there.
Have you tried my patch? I am not sure if it will fix everything but may
fix it.


This looks fine, but I want to fix the locking rather than just
hiding the issue. :)
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Borislav Petkov — 2013-05-20T13:23:56

I just confirmed that policy->cpus contains offlined cores with this:

diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 5af40ad82d23..e8c25f71e9b6 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
< at >< at > -169,6 +169,9 < at >< at > static inline void __gov_queue_work(int cpu, struct dbs_data *dbs_data,
 {
        struct cpu_dbs_common_info *cdbs = dbs_data->cdata->get_cpu_cdbs(cpu);
 
+       if (WARN_ON(!cpu_online(cpu)))
+               return;
+
        mod_delayed_work_on(cpu, system_wq, &cdbs->work, delay);
 }

see splats collection below.

And I don't think your fix above addresses the issue for the simple
reason that if cpus go offline *before* you do get_online_cpus(), then
policy->cpus will already contain offlined cpus.

Rather, a better fix would be, IMHO, to do this (it works here, of course):

---
diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
index 5af40ad82d23..58541b164494 100644
--- a/dri

Re: NULL pointer dereference

Ross Lagerwall — 2013-05-20T12:04:48

OK, I'll update and report back if it comes up again.

Thanks

Re: NULL pointer dereference

Viresh Kumar — 2013-05-20T09:46:56

On Mon, May 20, 2013 at 12:33 PM, Ross Lagerwall
<rosslagerwall< at >gmail.com> wrote:

Hi Ross,

Some known bugs are fixed during 3.10-rc2. Can you please check that to
see if it works for you?

They should already be there in linus's master branch.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule, round 2

Michael Wang — 2013-05-20T07:06:01

And I guess this may help to reduce the chance to trigger WARN:

diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 443442d..0f96013 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
< at >< at > -180,7 +180,7 < at >< at > void gov_queue_work(struct dbs_data *dbs_data,
struct cpufreq_policy *policy,
        if (!all_cpus) {
                __gov_queue_work(smp_processor_id(), dbs_data, delay);
        } else {
-               for_each_cpu(i, policy->cpus)
+               for_each_cpu_and(i, policy->cpus, cpu_online_mask)
                        __gov_queue_work(i, dbs_data, delay);
        }
 }

Well, disable irq will be better, anyway...still need folks who own that
driver to make the decision, so let's CC them :)

Regards,
Michael Wang



--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NULL pointer dereference

Ross Lagerwall — 2013-05-20T07:03:50

Hi,

Booting 3.10-rc1, I got a warning, then a stack dump then a NULL pointer
dereference all apparently in cpufreq code:
WARNING: at drivers/cpufreq/cpufreq_governor.c:251
cpufreq_governor_dbs+0x61e/0x680()
...

It seems to have happened during the initialization of udev.
This has only happened once out of several boots.

I have attached the boot log for completeness. I'm not sure if any other
information is needed.

Regards

Re: [PATCH] e_powersaver: Fix linker error when ACPI processor is a module

Viresh Kumar — 2013-05-20T04:18:04

Acked-by: Viresh Kumar <viresh.kumar< at >linaro.org>
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory

Francesco Lavra — 2013-05-19T18:43:31

Hi,

On 05/17/2013 01:26 PM, Viresh Kumar wrote:
[...]

Global symbol names should begin with a sensible prefix; in this case,
it looks like cpufreq_get_global_kobject and cpufreq_put_global_kobject
would be more appropriate names.

Regards,
Francesco
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cpufreq/intel_pstate: Add additional supported CPU ID

Theodore Ts'o — 2013-05-18T14:09:58

BTW, there are some good comments about this by Arjan in this G+ post

https://plus.google.com/117091380454742934025/posts/2vEekAsG2QT

I've tested a patch identical to this on my Thinkpad T430s and it
seems to work quite well for me.

- Ted
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html