cpufreq issue with K8 performance governor

Quoted 13 lines

Dave,

I am contacting you regarding a frequency scaling issue that I encountered with the performance governor in combination with CPU hotplug. In cpufreq.c CPU frequency is reduced to its minimum before the CPU gets unregistered and set offline. Does that have a particular reason? Since the (k8-)governor does not monitor CPU frequency that setting also applies then to the remaining CPU as well and lets the system run on the lowest frequency although performance is chose as the policy.

---
static int cpufreq_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{

[......]

Quoted 10 lines

                case CPU_DOWN_PREPARE_FROZEN:
                        if (unlikely(lock_policy_rwsem_write(cpu)))
                                BUG();

                        policy = cpufreq_cpu_data[cpu];
                        if (policy) {
                                __cpufreq_driver_target(policy, policy->min,
                                                CPUFREQ_RELATION_H);
                        }
                        __cpufreq_remove_dev(sys_dev);

This is the path taken when we call suspend.
To be honest, I doubt that reducing the speed has any benefit at all, as we're about to put the CPU to sleep anyway.

(btw, in future sending questions to [email protected] is a better
idea. The subsystem is sufficiently complex that at times, others can answer questions better than I can, especially with the various implementations all being subtley different).

Thanks,

Dave

Am Dienstag, 29. Mai 2007 18:06:21 schrieben Sie:

Quoted 36 lines · Peter Oruba

Quoted 13 lines

Dave,

I am contacting you regarding a frequency scaling issue that I encountered with the performance governor in combination with CPU hotplug. In cpufreq.c CPU frequency is reduced to its minimum before the CPU gets unregistered and set offline. Does that have a particular reason? Since the (k8-)governor does not monitor CPU frequency that setting also applies then to the remaining CPU as well and lets the system run on the lowest frequency although performance is chose as the policy.

---
static int cpufreq_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{

[......]

Quoted 10 lines

                case CPU_DOWN_PREPARE_FROZEN:
                        if (unlikely(lock_policy_rwsem_write(cpu)))
                                BUG();

                        policy = cpufreq_cpu_data[cpu];
                        if (policy) {
                                __cpufreq_driver_target(policy, policy->min,
                                                CPUFREQ_RELATION_H);
                        }
                        __cpufreq_remove_dev(sys_dev);

This is the path taken when we call suspend.
To be honest, I doubt that reducing the speed has any benefit at all, as we're about to put the CPU to sleep anyway.

(btw, in future sending questions to [email protected] is a better
idea. The subsystem is sufficiently complex that at times, others can answer questions better than I can, especially with the various implementations all being subtley different).

Thanks,

Quoted 2 lines

Dave

Okay, removing the __cpufreq_driver_target call would solve would obviously solve that problem (which btw also exists on Core2, as I tested a couple of minutes ago). Is it planned to be changed in the near future?

Thanks,
Peter