* [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-21 2:56 ` Pallipadi, Venkatesh
0 siblings, 0 replies; 36+ messages in thread
From: Pallipadi, Venkatesh @ 2003-10-21 2:56 UTC (permalink / raw)
To: cpufreq, linux-kernel, linux-acpi
Cc: Nakajima, Jun, Mallick, Asit K, Dominik Brodowski
[-- Attachment #1: Type: text/plain, Size: 9977 bytes --]
Patch 3/3: New dynamic cpufreq driver (called
DemandBasedSwitch driver), which periodically monitors CPU
usage and changes the CPU frequency based on the demand.
diffstat dbs3.patch
drivers/cpufreq/Kconfig | 25 ++++
drivers/cpufreq/Makefile | 1
drivers/cpufreq/cpufreq_dbs.c | 214
++++++++++++++++++++++++++++++++++++++++++
include/linux/cpufreq.h | 3
4 files changed, 243 insertions(+)
diff -purN linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c
linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c
--- linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c 1969-12-31
16:00:00.000000000 -0800
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c 2003-10-20
17:38:05.000000000 -0700
@@ -0,0 +1,214 @@
+/*
+ * drivers/cpufreq/cpufreq_dbs.c
+ *
+ * Copyright (C) 2001 Russell King
+ * (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ * (C) 2003 Venkatesh Pallipadi
<venkatesh.pallipadi@intel.com>.
+ * Jun Nakajima <jun.nakajima@intel.com>
+ *
+ * $Id:$
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/smp.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/ctype.h>
+#include <linux/cpufreq.h>
+#include <linux/sysctl.h>
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/sysfs.h>
+#include <linux/sched.h>
+#include <linux/kmod.h>
+#include <linux/workqueue.h>
+#include <linux/jiffies.h>
+#include <linux/config.h>
+#include <linux/kernel_stat.h>
+
+#define DBS_RATE (HZ/4) /* timer rate is 250ms */
+#define LOW_LATENCY_FREQUENCY_CHANGE_LIMIT 100 /* in uS */
+
+static void do_dbs_timer(void *data);
+
+typedef struct {
+ struct cpufreq_policy *cur_policy;
+ unsigned int prev_cpu_idle;
+ unsigned int enable;
+} ____cacheline_aligned cpu_dbs_info_t;
+static cpu_dbs_info_t cpu_dbs_info[NR_CPUS];
+
+static unsigned int dbs_enable; /* number of CPUs using DBS
policy */
+
+static DECLARE_MUTEX (dbs_sem);
+static DECLARE_WORK (dbs_work, do_dbs_timer, NULL);
+
+static void dbs_check_cpu(int cpu)
+{
+ unsigned int idle_ticks;
+
+ if (!cpu_dbs_info[cpu].enable)
+ return;
+
+ idle_ticks = kstat_cpu(cpu).cpustat.idle -
+ cpu_dbs_info[cpu].prev_cpu_idle;
+ cpu_dbs_info[cpu].prev_cpu_idle = kstat_cpu(cpu).cpustat.idle;
+
+ /*
+ * The current safe range is 20% to 80%
+ * - If current idle time is less than 20%, then we try to
+ * increase frequency
+ * - If current idle time is more than 80%, then we try to
+ * decrease frequency
+ */
+ if (idle_ticks < (DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur + 1,
+ CPUFREQ_RELATION_L);
+ else if (idle_ticks > (4 * DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur - 1,
+ CPUFREQ_RELATION_H);
+}
+
+static void do_dbs_timer(void *data)
+{
+ int i;
+ down(&dbs_sem);
+ for (i = 0; i < NR_CPUS; i++)
+ if (cpu_online(i))
+ dbs_check_cpu(i);
+ schedule_delayed_work(&dbs_work, DBS_RATE);
+ up(&dbs_sem);
+}
+
+static inline int dbs_timer_init(void)
+{
+ schedule_work(&dbs_work);
+ return 0;
+}
+
+static inline void dbs_timer_exit(void)
+{
+ cancel_delayed_work(&dbs_work);
+ return;
+}
+
+/************************** sysfs interface ************************/
+static ssize_t show_speed (struct cpufreq_policy *policy, char *buf)
+{
+ return sprintf (buf, "%u\n", policy->cur);
+}
+
+static struct freq_attr freq_attr_scaling_getspeed = {
+ .attr = { .name = "scaling_getspeed", .mode = 0444 },
+ .show = show_speed,
+};
+
+static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
+ unsigned int event)
+{
+ unsigned int cpu = policy->cpu;
+
+ switch (event) {
+ case CPUFREQ_GOV_START:
+ if ((!cpu_online(cpu)) || (!try_module_get(THIS_MODULE))
||
+ !policy->cur)
+ return -EINVAL;
+ if (policy->cpuinfo.transition_latency >
+ LOW_LATENCY_FREQUENCY_CHANGE_LIMIT)
+ return -EINVAL;
+ if (cpu_dbs_info[cpu].enable) /* Already enabled */
+ break;
+
+ printk(KERN_DEBUG "DBS START: cpu %d, max %d, min %d,
cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ cpu_dbs_info[cpu].cur_policy = policy;
+ cpu_dbs_info[cpu].prev_cpu_idle =
kstat_cpu(cpu).cpustat.idle;
+ cpu_dbs_info[cpu].enable = 1;
+ sysfs_create_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ dbs_enable++;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 1)
+ dbs_timer_init();
+
+ up(&dbs_sem);
+ break;
+
+ case CPUFREQ_GOV_STOP:
+ printk(KERN_DEBUG "DBS STOP: cpu %d, max %d, min %d, cur
%d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ sysfs_remove_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ cpu_dbs_info[cpu].enable = 0;
+ dbs_enable--;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 0)
+ dbs_timer_exit();
+
+ up(&dbs_sem);
+ module_put(THIS_MODULE);
+ break;
+
+ case CPUFREQ_GOV_LIMITS:
+ printk(KERN_DEBUG "DBS LIMIT: cpu %d, max %d, min %d,
cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ if (policy->max < cpu_dbs_info[cpu].cur_policy->cur)
+
__cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->max,
CPUFREQ_RELATION_H);
+ else if (policy->min >
cpu_dbs_info[cpu].cur_policy->cur)
+
__cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->min,
CPUFREQ_RELATION_L);
+ up(&dbs_sem);
+ break;
+ }
+ return 0;
+}
+
+struct cpufreq_governor cpufreq_gov_dbs = {
+ .name = "demandbased",
+ .governor = cpufreq_governor_dbs,
+ .owner = THIS_MODULE,
+};
+EXPORT_SYMBOL(cpufreq_gov_dbs);
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+ return cpufreq_register_governor(&cpufreq_gov_dbs);
+}
+
+static void __exit cpufreq_gov_dbs_exit(void)
+{
+ /* Make sure that the scheduled work is indeed not running */
+ flush_scheduled_work();
+ cpufreq_unregister_governor(&cpufreq_gov_dbs);
+}
+
+
+MODULE_AUTHOR ("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
+MODULE_DESCRIPTION ("DBS(Demand Based Switching)- "
+ "A dynamic processor frequency governor for "
+ "Low Latency Frequency Transition capable processors");
+MODULE_LICENSE ("GPL");
+
+module_init(cpufreq_gov_dbs_init);
+module_exit(cpufreq_gov_dbs_exit);
diff -purN linux-2.6.0-test7/drivers/cpufreq/Kconfig
linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig
--- linux-2.6.0-test7/drivers/cpufreq/Kconfig 2003-10-20
00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig 2003-10-20
17:27:57.000000000 -0700
@@ -35,6 +35,16 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE
programm shall be able to set the CPU dynamically without
having
to enable the userspace governor manually.
+config CPU_FREQ_DEFAULT_GOV_DEMANDBASED
+ bool "demandbased"
+ select CPU_FREQ_GOV_DEMANDBASED
+ help
+ Use the CPUFreq governor 'demandbased' as default. This
enables
+ kernel to dynamically motnitor the CPU usage and adjust the
+ CPU frequency accordingly, with no manual intervenation.
+ This will be enabled only if CPU supports 'Low Latency
+ Frequency Transitions'
+
endchoice
config CPU_FREQ_GOV_PERFORMANCE
@@ -68,6 +78,21 @@ config CPU_FREQ_GOV_USERSPACE
If in doubt, say Y.
+config CPU_FREQ_GOV_DEMANDBASED
+ tristate "Demand Based Switching - Dynamic cpufreq policy
governer"
+ depends on CPU_FREQ
+ help
+ This driver adds a cpufreq policy governer called Demand Based
+ Switching. The driver does a periodic polling and dynamically
+ changes frequency based on the processor utilization.
+ The policy depends on processor capability to
+ do fast frequency switching (i.e, very low latency frequency
+ transitions).
+
+ For details, take a look at linux/Documentation/cpu-freq.
+
+ If in doubt, say N.
+
config CPU_FREQ_24_API
bool "/proc/sys/cpu/ interface (2.4. / OLD)"
depends on CPU_FREQ && SYSCTL && CPU_FREQ_GOV_USERSPACE
diff -purN linux-2.6.0-test7/drivers/cpufreq/Makefile
linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile
--- linux-2.6.0-test7/drivers/cpufreq/Makefile 2003-10-20
00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile 2003-10-20
17:06:05.000000000 -0700
@@ -5,6 +5,7 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq.o
obj-$(CONFIG_CPU_FREQ_GOV_PERFORMANCE) += cpufreq_performance.o
obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE) += cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
+obj-$(CONFIG_CPU_FREQ_GOV_DEMANDBASED) += cpufreq_dbs.o
# CPUfreq cross-arch helpers
obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
diff -purN linux-2.6.0-test7/include/linux/cpufreq.h
linux-2.6.0-test7-dbs/include/linux/cpufreq.h
--- linux-2.6.0-test7/include/linux/cpufreq.h 2003-10-08
12:24:16.000000000 -0700
+++ linux-2.6.0-test7-dbs/include/linux/cpufreq.h 2003-10-20
17:36:34.000000000 -0700
@@ -303,6 +303,9 @@ extern struct cpufreq_governor cpufreq_g
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)
extern struct cpufreq_governor cpufreq_gov_userspace;
#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_userspace
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_DEMANDBASED)
+extern struct cpufreq_governor cpufreq_gov_dbs;
+#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
#endif
/*********************************************************************
[-- Attachment #2: dbs3.patch --]
[-- Type: application/octet-stream, Size: 9237 bytes --]
diff -purN linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c
--- linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c 2003-10-20 17:38:05.000000000 -0700
@@ -0,0 +1,214 @@
+/*
+ * drivers/cpufreq/cpufreq_dbs.c
+ *
+ * Copyright (C) 2001 Russell King
+ * (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ * (C) 2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
+ * Jun Nakajima <jun.nakajima@intel.com>
+ *
+ * $Id:$
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/smp.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/ctype.h>
+#include <linux/cpufreq.h>
+#include <linux/sysctl.h>
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/sysfs.h>
+#include <linux/sched.h>
+#include <linux/kmod.h>
+#include <linux/workqueue.h>
+#include <linux/jiffies.h>
+#include <linux/config.h>
+#include <linux/kernel_stat.h>
+
+#define DBS_RATE (HZ/4) /* timer rate is 250ms */
+#define LOW_LATENCY_FREQUENCY_CHANGE_LIMIT 100 /* in uS */
+
+static void do_dbs_timer(void *data);
+
+typedef struct {
+ struct cpufreq_policy *cur_policy;
+ unsigned int prev_cpu_idle;
+ unsigned int enable;
+} ____cacheline_aligned cpu_dbs_info_t;
+static cpu_dbs_info_t cpu_dbs_info[NR_CPUS];
+
+static unsigned int dbs_enable; /* number of CPUs using DBS policy */
+
+static DECLARE_MUTEX (dbs_sem);
+static DECLARE_WORK (dbs_work, do_dbs_timer, NULL);
+
+static void dbs_check_cpu(int cpu)
+{
+ unsigned int idle_ticks;
+
+ if (!cpu_dbs_info[cpu].enable)
+ return;
+
+ idle_ticks = kstat_cpu(cpu).cpustat.idle -
+ cpu_dbs_info[cpu].prev_cpu_idle;
+ cpu_dbs_info[cpu].prev_cpu_idle = kstat_cpu(cpu).cpustat.idle;
+
+ /*
+ * The current safe range is 20% to 80%
+ * - If current idle time is less than 20%, then we try to
+ * increase frequency
+ * - If current idle time is more than 80%, then we try to
+ * decrease frequency
+ */
+ if (idle_ticks < (DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur + 1,
+ CPUFREQ_RELATION_L);
+ else if (idle_ticks > (4 * DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur - 1,
+ CPUFREQ_RELATION_H);
+}
+
+static void do_dbs_timer(void *data)
+{
+ int i;
+ down(&dbs_sem);
+ for (i = 0; i < NR_CPUS; i++)
+ if (cpu_online(i))
+ dbs_check_cpu(i);
+ schedule_delayed_work(&dbs_work, DBS_RATE);
+ up(&dbs_sem);
+}
+
+static inline int dbs_timer_init(void)
+{
+ schedule_work(&dbs_work);
+ return 0;
+}
+
+static inline void dbs_timer_exit(void)
+{
+ cancel_delayed_work(&dbs_work);
+ return;
+}
+
+/************************** sysfs interface ************************/
+static ssize_t show_speed (struct cpufreq_policy *policy, char *buf)
+{
+ return sprintf (buf, "%u\n", policy->cur);
+}
+
+static struct freq_attr freq_attr_scaling_getspeed = {
+ .attr = { .name = "scaling_getspeed", .mode = 0444 },
+ .show = show_speed,
+};
+
+static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
+ unsigned int event)
+{
+ unsigned int cpu = policy->cpu;
+
+ switch (event) {
+ case CPUFREQ_GOV_START:
+ if ((!cpu_online(cpu)) || (!try_module_get(THIS_MODULE)) ||
+ !policy->cur)
+ return -EINVAL;
+ if (policy->cpuinfo.transition_latency >
+ LOW_LATENCY_FREQUENCY_CHANGE_LIMIT)
+ return -EINVAL;
+ if (cpu_dbs_info[cpu].enable) /* Already enabled */
+ break;
+
+ printk(KERN_DEBUG "DBS START: cpu %d, max %d, min %d, cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ cpu_dbs_info[cpu].cur_policy = policy;
+ cpu_dbs_info[cpu].prev_cpu_idle = kstat_cpu(cpu).cpustat.idle;
+ cpu_dbs_info[cpu].enable = 1;
+ sysfs_create_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ dbs_enable++;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 1)
+ dbs_timer_init();
+
+ up(&dbs_sem);
+ break;
+
+ case CPUFREQ_GOV_STOP:
+ printk(KERN_DEBUG "DBS STOP: cpu %d, max %d, min %d, cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ sysfs_remove_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ cpu_dbs_info[cpu].enable = 0;
+ dbs_enable--;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 0)
+ dbs_timer_exit();
+
+ up(&dbs_sem);
+ module_put(THIS_MODULE);
+ break;
+
+ case CPUFREQ_GOV_LIMITS:
+ printk(KERN_DEBUG "DBS LIMIT: cpu %d, max %d, min %d, cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ if (policy->max < cpu_dbs_info[cpu].cur_policy->cur)
+ __cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->max, CPUFREQ_RELATION_H);
+ else if (policy->min > cpu_dbs_info[cpu].cur_policy->cur)
+ __cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->min, CPUFREQ_RELATION_L);
+ up(&dbs_sem);
+ break;
+ }
+ return 0;
+}
+
+struct cpufreq_governor cpufreq_gov_dbs = {
+ .name = "demandbased",
+ .governor = cpufreq_governor_dbs,
+ .owner = THIS_MODULE,
+};
+EXPORT_SYMBOL(cpufreq_gov_dbs);
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+ return cpufreq_register_governor(&cpufreq_gov_dbs);
+}
+
+static void __exit cpufreq_gov_dbs_exit(void)
+{
+ /* Make sure that the scheduled work is indeed not running */
+ flush_scheduled_work();
+ cpufreq_unregister_governor(&cpufreq_gov_dbs);
+}
+
+
+MODULE_AUTHOR ("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
+MODULE_DESCRIPTION ("DBS(Demand Based Switching)- "
+ "A dynamic processor frequency governor for "
+ "Low Latency Frequency Transition capable processors");
+MODULE_LICENSE ("GPL");
+
+module_init(cpufreq_gov_dbs_init);
+module_exit(cpufreq_gov_dbs_exit);
diff -purN linux-2.6.0-test7/drivers/cpufreq/Kconfig linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig
--- linux-2.6.0-test7/drivers/cpufreq/Kconfig 2003-10-20 00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig 2003-10-20 17:27:57.000000000 -0700
@@ -35,6 +35,16 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE
programm shall be able to set the CPU dynamically without having
to enable the userspace governor manually.
+config CPU_FREQ_DEFAULT_GOV_DEMANDBASED
+ bool "demandbased"
+ select CPU_FREQ_GOV_DEMANDBASED
+ help
+ Use the CPUFreq governor 'demandbased' as default. This enables
+ kernel to dynamically motnitor the CPU usage and adjust the
+ CPU frequency accordingly, with no manual intervenation.
+ This will be enabled only if CPU supports 'Low Latency
+ Frequency Transitions'
+
endchoice
config CPU_FREQ_GOV_PERFORMANCE
@@ -68,6 +78,21 @@ config CPU_FREQ_GOV_USERSPACE
If in doubt, say Y.
+config CPU_FREQ_GOV_DEMANDBASED
+ tristate "Demand Based Switching - Dynamic cpufreq policy governer"
+ depends on CPU_FREQ
+ help
+ This driver adds a cpufreq policy governer called Demand Based
+ Switching. The driver does a periodic polling and dynamically
+ changes frequency based on the processor utilization.
+ The policy depends on processor capability to
+ do fast frequency switching (i.e, very low latency frequency
+ transitions).
+
+ For details, take a look at linux/Documentation/cpu-freq.
+
+ If in doubt, say N.
+
config CPU_FREQ_24_API
bool "/proc/sys/cpu/ interface (2.4. / OLD)"
depends on CPU_FREQ && SYSCTL && CPU_FREQ_GOV_USERSPACE
diff -purN linux-2.6.0-test7/drivers/cpufreq/Makefile linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile
--- linux-2.6.0-test7/drivers/cpufreq/Makefile 2003-10-20 00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile 2003-10-20 17:06:05.000000000 -0700
@@ -5,6 +5,7 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq.o
obj-$(CONFIG_CPU_FREQ_GOV_PERFORMANCE) += cpufreq_performance.o
obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE) += cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
+obj-$(CONFIG_CPU_FREQ_GOV_DEMANDBASED) += cpufreq_dbs.o
# CPUfreq cross-arch helpers
obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
diff -purN linux-2.6.0-test7/include/linux/cpufreq.h linux-2.6.0-test7-dbs/include/linux/cpufreq.h
--- linux-2.6.0-test7/include/linux/cpufreq.h 2003-10-08 12:24:16.000000000 -0700
+++ linux-2.6.0-test7-dbs/include/linux/cpufreq.h 2003-10-20 17:36:34.000000000 -0700
@@ -303,6 +303,9 @@ extern struct cpufreq_governor cpufreq_g
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)
extern struct cpufreq_governor cpufreq_gov_userspace;
#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_userspace
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_DEMANDBASED)
+extern struct cpufreq_governor cpufreq_gov_dbs;
+#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
#endif
/*********************************************************************
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-21 2:56 ` Pallipadi, Venkatesh
0 siblings, 0 replies; 36+ messages in thread
From: Pallipadi, Venkatesh @ 2003-10-21 2:56 UTC (permalink / raw)
To: cpufreq, linux-kernel, linux-acpi
Cc: Mallick, Asit K, Nakajima, Jun, Dominik Brodowski
[-- Attachment #1: Type: text/plain, Size: 9977 bytes --]
Patch 3/3: New dynamic cpufreq driver (called
DemandBasedSwitch driver), which periodically monitors CPU
usage and changes the CPU frequency based on the demand.
diffstat dbs3.patch
drivers/cpufreq/Kconfig | 25 ++++
drivers/cpufreq/Makefile | 1
drivers/cpufreq/cpufreq_dbs.c | 214
++++++++++++++++++++++++++++++++++++++++++
include/linux/cpufreq.h | 3
4 files changed, 243 insertions(+)
diff -purN linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c
linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c
--- linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c 1969-12-31
16:00:00.000000000 -0800
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c 2003-10-20
17:38:05.000000000 -0700
@@ -0,0 +1,214 @@
+/*
+ * drivers/cpufreq/cpufreq_dbs.c
+ *
+ * Copyright (C) 2001 Russell King
+ * (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ * (C) 2003 Venkatesh Pallipadi
<venkatesh.pallipadi@intel.com>.
+ * Jun Nakajima <jun.nakajima@intel.com>
+ *
+ * $Id:$
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/smp.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/ctype.h>
+#include <linux/cpufreq.h>
+#include <linux/sysctl.h>
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/sysfs.h>
+#include <linux/sched.h>
+#include <linux/kmod.h>
+#include <linux/workqueue.h>
+#include <linux/jiffies.h>
+#include <linux/config.h>
+#include <linux/kernel_stat.h>
+
+#define DBS_RATE (HZ/4) /* timer rate is 250ms */
+#define LOW_LATENCY_FREQUENCY_CHANGE_LIMIT 100 /* in uS */
+
+static void do_dbs_timer(void *data);
+
+typedef struct {
+ struct cpufreq_policy *cur_policy;
+ unsigned int prev_cpu_idle;
+ unsigned int enable;
+} ____cacheline_aligned cpu_dbs_info_t;
+static cpu_dbs_info_t cpu_dbs_info[NR_CPUS];
+
+static unsigned int dbs_enable; /* number of CPUs using DBS
policy */
+
+static DECLARE_MUTEX (dbs_sem);
+static DECLARE_WORK (dbs_work, do_dbs_timer, NULL);
+
+static void dbs_check_cpu(int cpu)
+{
+ unsigned int idle_ticks;
+
+ if (!cpu_dbs_info[cpu].enable)
+ return;
+
+ idle_ticks = kstat_cpu(cpu).cpustat.idle -
+ cpu_dbs_info[cpu].prev_cpu_idle;
+ cpu_dbs_info[cpu].prev_cpu_idle = kstat_cpu(cpu).cpustat.idle;
+
+ /*
+ * The current safe range is 20% to 80%
+ * - If current idle time is less than 20%, then we try to
+ * increase frequency
+ * - If current idle time is more than 80%, then we try to
+ * decrease frequency
+ */
+ if (idle_ticks < (DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur + 1,
+ CPUFREQ_RELATION_L);
+ else if (idle_ticks > (4 * DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur - 1,
+ CPUFREQ_RELATION_H);
+}
+
+static void do_dbs_timer(void *data)
+{
+ int i;
+ down(&dbs_sem);
+ for (i = 0; i < NR_CPUS; i++)
+ if (cpu_online(i))
+ dbs_check_cpu(i);
+ schedule_delayed_work(&dbs_work, DBS_RATE);
+ up(&dbs_sem);
+}
+
+static inline int dbs_timer_init(void)
+{
+ schedule_work(&dbs_work);
+ return 0;
+}
+
+static inline void dbs_timer_exit(void)
+{
+ cancel_delayed_work(&dbs_work);
+ return;
+}
+
+/************************** sysfs interface ************************/
+static ssize_t show_speed (struct cpufreq_policy *policy, char *buf)
+{
+ return sprintf (buf, "%u\n", policy->cur);
+}
+
+static struct freq_attr freq_attr_scaling_getspeed = {
+ .attr = { .name = "scaling_getspeed", .mode = 0444 },
+ .show = show_speed,
+};
+
+static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
+ unsigned int event)
+{
+ unsigned int cpu = policy->cpu;
+
+ switch (event) {
+ case CPUFREQ_GOV_START:
+ if ((!cpu_online(cpu)) || (!try_module_get(THIS_MODULE))
||
+ !policy->cur)
+ return -EINVAL;
+ if (policy->cpuinfo.transition_latency >
+ LOW_LATENCY_FREQUENCY_CHANGE_LIMIT)
+ return -EINVAL;
+ if (cpu_dbs_info[cpu].enable) /* Already enabled */
+ break;
+
+ printk(KERN_DEBUG "DBS START: cpu %d, max %d, min %d,
cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ cpu_dbs_info[cpu].cur_policy = policy;
+ cpu_dbs_info[cpu].prev_cpu_idle =
kstat_cpu(cpu).cpustat.idle;
+ cpu_dbs_info[cpu].enable = 1;
+ sysfs_create_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ dbs_enable++;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 1)
+ dbs_timer_init();
+
+ up(&dbs_sem);
+ break;
+
+ case CPUFREQ_GOV_STOP:
+ printk(KERN_DEBUG "DBS STOP: cpu %d, max %d, min %d, cur
%d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ sysfs_remove_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ cpu_dbs_info[cpu].enable = 0;
+ dbs_enable--;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 0)
+ dbs_timer_exit();
+
+ up(&dbs_sem);
+ module_put(THIS_MODULE);
+ break;
+
+ case CPUFREQ_GOV_LIMITS:
+ printk(KERN_DEBUG "DBS LIMIT: cpu %d, max %d, min %d,
cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ if (policy->max < cpu_dbs_info[cpu].cur_policy->cur)
+
__cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->max,
CPUFREQ_RELATION_H);
+ else if (policy->min >
cpu_dbs_info[cpu].cur_policy->cur)
+
__cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->min,
CPUFREQ_RELATION_L);
+ up(&dbs_sem);
+ break;
+ }
+ return 0;
+}
+
+struct cpufreq_governor cpufreq_gov_dbs = {
+ .name = "demandbased",
+ .governor = cpufreq_governor_dbs,
+ .owner = THIS_MODULE,
+};
+EXPORT_SYMBOL(cpufreq_gov_dbs);
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+ return cpufreq_register_governor(&cpufreq_gov_dbs);
+}
+
+static void __exit cpufreq_gov_dbs_exit(void)
+{
+ /* Make sure that the scheduled work is indeed not running */
+ flush_scheduled_work();
+ cpufreq_unregister_governor(&cpufreq_gov_dbs);
+}
+
+
+MODULE_AUTHOR ("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
+MODULE_DESCRIPTION ("DBS(Demand Based Switching)- "
+ "A dynamic processor frequency governor for "
+ "Low Latency Frequency Transition capable processors");
+MODULE_LICENSE ("GPL");
+
+module_init(cpufreq_gov_dbs_init);
+module_exit(cpufreq_gov_dbs_exit);
diff -purN linux-2.6.0-test7/drivers/cpufreq/Kconfig
linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig
--- linux-2.6.0-test7/drivers/cpufreq/Kconfig 2003-10-20
00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig 2003-10-20
17:27:57.000000000 -0700
@@ -35,6 +35,16 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE
programm shall be able to set the CPU dynamically without
having
to enable the userspace governor manually.
+config CPU_FREQ_DEFAULT_GOV_DEMANDBASED
+ bool "demandbased"
+ select CPU_FREQ_GOV_DEMANDBASED
+ help
+ Use the CPUFreq governor 'demandbased' as default. This
enables
+ kernel to dynamically motnitor the CPU usage and adjust the
+ CPU frequency accordingly, with no manual intervenation.
+ This will be enabled only if CPU supports 'Low Latency
+ Frequency Transitions'
+
endchoice
config CPU_FREQ_GOV_PERFORMANCE
@@ -68,6 +78,21 @@ config CPU_FREQ_GOV_USERSPACE
If in doubt, say Y.
+config CPU_FREQ_GOV_DEMANDBASED
+ tristate "Demand Based Switching - Dynamic cpufreq policy
governer"
+ depends on CPU_FREQ
+ help
+ This driver adds a cpufreq policy governer called Demand Based
+ Switching. The driver does a periodic polling and dynamically
+ changes frequency based on the processor utilization.
+ The policy depends on processor capability to
+ do fast frequency switching (i.e, very low latency frequency
+ transitions).
+
+ For details, take a look at linux/Documentation/cpu-freq.
+
+ If in doubt, say N.
+
config CPU_FREQ_24_API
bool "/proc/sys/cpu/ interface (2.4. / OLD)"
depends on CPU_FREQ && SYSCTL && CPU_FREQ_GOV_USERSPACE
diff -purN linux-2.6.0-test7/drivers/cpufreq/Makefile
linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile
--- linux-2.6.0-test7/drivers/cpufreq/Makefile 2003-10-20
00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile 2003-10-20
17:06:05.000000000 -0700
@@ -5,6 +5,7 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq.o
obj-$(CONFIG_CPU_FREQ_GOV_PERFORMANCE) += cpufreq_performance.o
obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE) += cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
+obj-$(CONFIG_CPU_FREQ_GOV_DEMANDBASED) += cpufreq_dbs.o
# CPUfreq cross-arch helpers
obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
diff -purN linux-2.6.0-test7/include/linux/cpufreq.h
linux-2.6.0-test7-dbs/include/linux/cpufreq.h
--- linux-2.6.0-test7/include/linux/cpufreq.h 2003-10-08
12:24:16.000000000 -0700
+++ linux-2.6.0-test7-dbs/include/linux/cpufreq.h 2003-10-20
17:36:34.000000000 -0700
@@ -303,6 +303,9 @@ extern struct cpufreq_governor cpufreq_g
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)
extern struct cpufreq_governor cpufreq_gov_userspace;
#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_userspace
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_DEMANDBASED)
+extern struct cpufreq_governor cpufreq_gov_dbs;
+#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
#endif
/*********************************************************************
[-- Attachment #2: dbs3.patch --]
[-- Type: application/octet-stream, Size: 9237 bytes --]
diff -purN linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c
--- linux-2.6.0-test7/drivers/cpufreq/cpufreq_dbs.c 1969-12-31 16:00:00.000000000 -0800
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/cpufreq_dbs.c 2003-10-20 17:38:05.000000000 -0700
@@ -0,0 +1,214 @@
+/*
+ * drivers/cpufreq/cpufreq_dbs.c
+ *
+ * Copyright (C) 2001 Russell King
+ * (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
+ * (C) 2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
+ * Jun Nakajima <jun.nakajima@intel.com>
+ *
+ * $Id:$
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/smp.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/ctype.h>
+#include <linux/cpufreq.h>
+#include <linux/sysctl.h>
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/sysfs.h>
+#include <linux/sched.h>
+#include <linux/kmod.h>
+#include <linux/workqueue.h>
+#include <linux/jiffies.h>
+#include <linux/config.h>
+#include <linux/kernel_stat.h>
+
+#define DBS_RATE (HZ/4) /* timer rate is 250ms */
+#define LOW_LATENCY_FREQUENCY_CHANGE_LIMIT 100 /* in uS */
+
+static void do_dbs_timer(void *data);
+
+typedef struct {
+ struct cpufreq_policy *cur_policy;
+ unsigned int prev_cpu_idle;
+ unsigned int enable;
+} ____cacheline_aligned cpu_dbs_info_t;
+static cpu_dbs_info_t cpu_dbs_info[NR_CPUS];
+
+static unsigned int dbs_enable; /* number of CPUs using DBS policy */
+
+static DECLARE_MUTEX (dbs_sem);
+static DECLARE_WORK (dbs_work, do_dbs_timer, NULL);
+
+static void dbs_check_cpu(int cpu)
+{
+ unsigned int idle_ticks;
+
+ if (!cpu_dbs_info[cpu].enable)
+ return;
+
+ idle_ticks = kstat_cpu(cpu).cpustat.idle -
+ cpu_dbs_info[cpu].prev_cpu_idle;
+ cpu_dbs_info[cpu].prev_cpu_idle = kstat_cpu(cpu).cpustat.idle;
+
+ /*
+ * The current safe range is 20% to 80%
+ * - If current idle time is less than 20%, then we try to
+ * increase frequency
+ * - If current idle time is more than 80%, then we try to
+ * decrease frequency
+ */
+ if (idle_ticks < (DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur + 1,
+ CPUFREQ_RELATION_L);
+ else if (idle_ticks > (4 * DBS_RATE / 5))
+ cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ cpu_dbs_info[cpu].cur_policy->cur - 1,
+ CPUFREQ_RELATION_H);
+}
+
+static void do_dbs_timer(void *data)
+{
+ int i;
+ down(&dbs_sem);
+ for (i = 0; i < NR_CPUS; i++)
+ if (cpu_online(i))
+ dbs_check_cpu(i);
+ schedule_delayed_work(&dbs_work, DBS_RATE);
+ up(&dbs_sem);
+}
+
+static inline int dbs_timer_init(void)
+{
+ schedule_work(&dbs_work);
+ return 0;
+}
+
+static inline void dbs_timer_exit(void)
+{
+ cancel_delayed_work(&dbs_work);
+ return;
+}
+
+/************************** sysfs interface ************************/
+static ssize_t show_speed (struct cpufreq_policy *policy, char *buf)
+{
+ return sprintf (buf, "%u\n", policy->cur);
+}
+
+static struct freq_attr freq_attr_scaling_getspeed = {
+ .attr = { .name = "scaling_getspeed", .mode = 0444 },
+ .show = show_speed,
+};
+
+static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
+ unsigned int event)
+{
+ unsigned int cpu = policy->cpu;
+
+ switch (event) {
+ case CPUFREQ_GOV_START:
+ if ((!cpu_online(cpu)) || (!try_module_get(THIS_MODULE)) ||
+ !policy->cur)
+ return -EINVAL;
+ if (policy->cpuinfo.transition_latency >
+ LOW_LATENCY_FREQUENCY_CHANGE_LIMIT)
+ return -EINVAL;
+ if (cpu_dbs_info[cpu].enable) /* Already enabled */
+ break;
+
+ printk(KERN_DEBUG "DBS START: cpu %d, max %d, min %d, cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ cpu_dbs_info[cpu].cur_policy = policy;
+ cpu_dbs_info[cpu].prev_cpu_idle = kstat_cpu(cpu).cpustat.idle;
+ cpu_dbs_info[cpu].enable = 1;
+ sysfs_create_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ dbs_enable++;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 1)
+ dbs_timer_init();
+
+ up(&dbs_sem);
+ break;
+
+ case CPUFREQ_GOV_STOP:
+ printk(KERN_DEBUG "DBS STOP: cpu %d, max %d, min %d, cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ sysfs_remove_file(&policy->kobj,
+ &freq_attr_scaling_getspeed.attr);
+ cpu_dbs_info[cpu].enable = 0;
+ dbs_enable--;
+ /*
+ * Start the timerschedule work, when this governer
+ * is used for first time
+ */
+ if (dbs_enable == 0)
+ dbs_timer_exit();
+
+ up(&dbs_sem);
+ module_put(THIS_MODULE);
+ break;
+
+ case CPUFREQ_GOV_LIMITS:
+ printk(KERN_DEBUG "DBS LIMIT: cpu %d, max %d, min %d, cur %d\n",
+ policy->cpu, policy->max,
+ policy->min, policy->cur);
+ down(&dbs_sem);
+ if (policy->max < cpu_dbs_info[cpu].cur_policy->cur)
+ __cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->max, CPUFREQ_RELATION_H);
+ else if (policy->min > cpu_dbs_info[cpu].cur_policy->cur)
+ __cpufreq_driver_target(cpu_dbs_info[cpu].cur_policy,
+ policy->min, CPUFREQ_RELATION_L);
+ up(&dbs_sem);
+ break;
+ }
+ return 0;
+}
+
+struct cpufreq_governor cpufreq_gov_dbs = {
+ .name = "demandbased",
+ .governor = cpufreq_governor_dbs,
+ .owner = THIS_MODULE,
+};
+EXPORT_SYMBOL(cpufreq_gov_dbs);
+
+static int __init cpufreq_gov_dbs_init(void)
+{
+ return cpufreq_register_governor(&cpufreq_gov_dbs);
+}
+
+static void __exit cpufreq_gov_dbs_exit(void)
+{
+ /* Make sure that the scheduled work is indeed not running */
+ flush_scheduled_work();
+ cpufreq_unregister_governor(&cpufreq_gov_dbs);
+}
+
+
+MODULE_AUTHOR ("Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>");
+MODULE_DESCRIPTION ("DBS(Demand Based Switching)- "
+ "A dynamic processor frequency governor for "
+ "Low Latency Frequency Transition capable processors");
+MODULE_LICENSE ("GPL");
+
+module_init(cpufreq_gov_dbs_init);
+module_exit(cpufreq_gov_dbs_exit);
diff -purN linux-2.6.0-test7/drivers/cpufreq/Kconfig linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig
--- linux-2.6.0-test7/drivers/cpufreq/Kconfig 2003-10-20 00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Kconfig 2003-10-20 17:27:57.000000000 -0700
@@ -35,6 +35,16 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE
programm shall be able to set the CPU dynamically without having
to enable the userspace governor manually.
+config CPU_FREQ_DEFAULT_GOV_DEMANDBASED
+ bool "demandbased"
+ select CPU_FREQ_GOV_DEMANDBASED
+ help
+ Use the CPUFreq governor 'demandbased' as default. This enables
+ kernel to dynamically motnitor the CPU usage and adjust the
+ CPU frequency accordingly, with no manual intervenation.
+ This will be enabled only if CPU supports 'Low Latency
+ Frequency Transitions'
+
endchoice
config CPU_FREQ_GOV_PERFORMANCE
@@ -68,6 +78,21 @@ config CPU_FREQ_GOV_USERSPACE
If in doubt, say Y.
+config CPU_FREQ_GOV_DEMANDBASED
+ tristate "Demand Based Switching - Dynamic cpufreq policy governer"
+ depends on CPU_FREQ
+ help
+ This driver adds a cpufreq policy governer called Demand Based
+ Switching. The driver does a periodic polling and dynamically
+ changes frequency based on the processor utilization.
+ The policy depends on processor capability to
+ do fast frequency switching (i.e, very low latency frequency
+ transitions).
+
+ For details, take a look at linux/Documentation/cpu-freq.
+
+ If in doubt, say N.
+
config CPU_FREQ_24_API
bool "/proc/sys/cpu/ interface (2.4. / OLD)"
depends on CPU_FREQ && SYSCTL && CPU_FREQ_GOV_USERSPACE
diff -purN linux-2.6.0-test7/drivers/cpufreq/Makefile linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile
--- linux-2.6.0-test7/drivers/cpufreq/Makefile 2003-10-20 00:24:33.000000000 -0700
+++ linux-2.6.0-test7-dbs/drivers/cpufreq/Makefile 2003-10-20 17:06:05.000000000 -0700
@@ -5,6 +5,7 @@ obj-$(CONFIG_CPU_FREQ) += cpufreq.o
obj-$(CONFIG_CPU_FREQ_GOV_PERFORMANCE) += cpufreq_performance.o
obj-$(CONFIG_CPU_FREQ_GOV_POWERSAVE) += cpufreq_powersave.o
obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) += cpufreq_userspace.o
+obj-$(CONFIG_CPU_FREQ_GOV_DEMANDBASED) += cpufreq_dbs.o
# CPUfreq cross-arch helpers
obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
diff -purN linux-2.6.0-test7/include/linux/cpufreq.h linux-2.6.0-test7-dbs/include/linux/cpufreq.h
--- linux-2.6.0-test7/include/linux/cpufreq.h 2003-10-08 12:24:16.000000000 -0700
+++ linux-2.6.0-test7-dbs/include/linux/cpufreq.h 2003-10-20 17:36:34.000000000 -0700
@@ -303,6 +303,9 @@ extern struct cpufreq_governor cpufreq_g
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE)
extern struct cpufreq_governor cpufreq_gov_userspace;
#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_userspace
+#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_DEMANDBASED)
+extern struct cpufreq_governor cpufreq_gov_dbs;
+#define CPUFREQ_DEFAULT_GOVERNOR &cpufreq_gov_dbs
#endif
/*********************************************************************
[-- Attachment #3: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 2:56 ` Pallipadi, Venkatesh
@ 2003-10-21 8:38 ` Arjan van de Ven
-1 siblings, 0 replies; 36+ messages in thread
From: Arjan van de Ven @ 2003-10-21 8:38 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: cpufreq, linux-kernel, linux-acpi, Mallick, Asit K, Nakajima,
Jun, Dominik Brodowski
[-- Attachment #1: Type: text/plain, Size: 843 bytes --]
On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote:
> Patch 3/3: New dynamic cpufreq driver (called
> DemandBasedSwitch driver), which periodically monitors CPU
> usage and changes the CPU frequency based on the demand.
it's all nice code and such, but I still wonder why this can't be done
by a userland policy daemon. The 2.6 kernel has the infrastructure to
give very detailed information to userspace (eg top etc) about idle
percentages...... I didn't see anything in this driver that couldn't be
done from userspace.
Note that I'm not totally against doing some of this in the kernel; I
can well see the point of say, detecting an IRQ overload and based on
that, go to max speed in the kernel because it's a situation where
userspace doesn't even run; but the patch as is doesn't do any such
advanced things...
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-21 8:38 ` Arjan van de Ven
0 siblings, 0 replies; 36+ messages in thread
From: Arjan van de Ven @ 2003-10-21 8:38 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: cpufreq, Nakajima, Jun, linux-acpi, Mallick, Asit K,
linux-kernel, Dominik Brodowski
[-- Attachment #1.1: Type: text/plain, Size: 843 bytes --]
On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote:
> Patch 3/3: New dynamic cpufreq driver (called
> DemandBasedSwitch driver), which periodically monitors CPU
> usage and changes the CPU frequency based on the demand.
it's all nice code and such, but I still wonder why this can't be done
by a userland policy daemon. The 2.6 kernel has the infrastructure to
give very detailed information to userspace (eg top etc) about idle
percentages...... I didn't see anything in this driver that couldn't be
done from userspace.
Note that I'm not totally against doing some of this in the kernel; I
can well see the point of say, detecting an IRQ overload and based on
that, go to max speed in the kernel because it's a situation where
userspace doesn't even run; but the patch as is doesn't do any such
advanced things...
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 8:38 ` Arjan van de Ven
@ 2003-10-21 9:59 ` Mattia Dongili
-1 siblings, 0 replies; 36+ messages in thread
From: Mattia Dongili @ 2003-10-21 9:59 UTC (permalink / raw)
To: cpufreq, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
On Tue, Oct 21, 2003 at 10:38:53AM +0200, Arjan van de Ven wrote:
> On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote:
> > Patch 3/3: New dynamic cpufreq driver (called
> > DemandBasedSwitch driver), which periodically monitors CPU
> > usage and changes the CPU frequency based on the demand.
>
>
> it's all nice code and such, but I still wonder why this can't be done
> by a userland policy daemon. The 2.6 kernel has the infrastructure to
> give very detailed information to userspace (eg top etc) about idle
> percentages...... I didn't see anything in this driver that couldn't be
> done from userspace.
I remember Linus forcing a kernel only policy management:
http://www.linux.org.uk/mailman/private/cpufreq/2002-August/000865.html
Also: I think the userspace governor is a workaround to allow userspace
policies.
ciao
--
mattia
:wq!
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-21 9:59 ` Mattia Dongili
0 siblings, 0 replies; 36+ messages in thread
From: Mattia Dongili @ 2003-10-21 9:59 UTC (permalink / raw)
To: cpufreq, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]
On Tue, Oct 21, 2003 at 10:38:53AM +0200, Arjan van de Ven wrote:
> On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote:
> > Patch 3/3: New dynamic cpufreq driver (called
> > DemandBasedSwitch driver), which periodically monitors CPU
> > usage and changes the CPU frequency based on the demand.
>
>
> it's all nice code and such, but I still wonder why this can't be done
> by a userland policy daemon. The 2.6 kernel has the infrastructure to
> give very detailed information to userspace (eg top etc) about idle
> percentages...... I didn't see anything in this driver that couldn't be
> done from userspace.
I remember Linus forcing a kernel only policy management:
http://www.linux.org.uk/mailman/private/cpufreq/2002-August/000865.html
Also: I think the userspace governor is a workaround to allow userspace
policies.
ciao
--
mattia
:wq!
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 9:59 ` Mattia Dongili
(?)
@ 2003-10-21 10:17 ` Wichert Akkerman
2003-10-21 10:52 ` Mattia Dongili
-1 siblings, 1 reply; 36+ messages in thread
From: Wichert Akkerman @ 2003-10-21 10:17 UTC (permalink / raw)
To: linux-kernel; +Cc: cpufreq
Previously Mattia Dongili wrote:
> I remember Linus forcing a kernel only policy management:
> http://www.linux.org.uk/mailman/private/cpufreq/2002-August/000865.html
That archive is password-protected..
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 10:17 ` Wichert Akkerman
@ 2003-10-21 10:52 ` Mattia Dongili
2003-10-21 12:59 ` Wichert Akkerman
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Mattia Dongili @ 2003-10-21 10:52 UTC (permalink / raw)
To: linux-kernel, cpufreq
On Tue, Oct 21, 2003 at 12:17:37PM +0200, Wichert Akkerman wrote:
> Previously Mattia Dongili wrote:
> > I remember Linus forcing a kernel only policy management:
> > http://www.linux.org.uk/mailman/private/cpufreq/2002-August/000865.html
>
> That archive is password-protected..
<QUOTE>
On Wed, 28 Aug 2002, Dominik Brodowski wrote:
>
> The following patches add CPU frequency and volatage scaling
> support (Intel SpeedStep, AMD PowerNow, etc.) to kernel 2.5.32
The thing is, this interface appears fundamentally broken with respect to
CPU's that change their frequency on the fly. I happen to know one such
CPU rather well myself.
What is this interface supposed to do about a CPU that can change its
frequency dynamically several hundred times a second? Having the OS
control it simply isn't an option - the overhead of the control is _way_
more than is acceptable at that level.
In short, this interface is too broken to be called generic.
A quote from Peter Anvin:
"What is worse is that the interface is, in my opinion, fundamentally
broken for *ALL* CPUs. It doesn't present a policy interface to the
kernel, instead it presents a frequency-setting interface and expect
the policy to be done in userspace. The kernel is the only part of the
system which has sufficient information (idle times of all CPUs, for
example) to do a decent job managing the CPU frequency efficiently.
On Transmeta CPUs this policy should simply be passed down to CMS, of
course; on other CPUs the kernel needs to manage it."
In other words: there is no valid way that a _user_ can set the policy
right now: the user can set the frequency, but since any sane policy
depends on how busy the CPU is, the user isn't even, the right person to
_do_ that, since the user doesn't _know_.
Also note that policy is not just about how busy the CPU is, but also
about how _hot_ the CPU is. Again, a user-mode application (that maybe
polls the situation every minute or so), simply _cannot_ handle this
situation. You need to have the ability to poll the CPU tens of times a
second to react to heat events, and clearly user mode cannot do that
without impacting performance in a big way.
The interface needs to be improved upon. It is simply _not_ valid to say
"run at this speed" as the primary policy.
Linus
</QUOTE>
anyway there has been a full discussion regarding this issue.
The result has been a major redesing of the cpufreq interface in
accordance to Linus' statements
Note: if you're subscribed to the cpufreq list you have a password to
enter at the propmt :)
ciao
--
mattia
:wq!
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 10:52 ` Mattia Dongili
@ 2003-10-21 12:59 ` Wichert Akkerman
2003-10-21 15:36 ` Daniel Thor Kristjansson
2003-10-21 19:23 ` Carl Thompson
2 siblings, 0 replies; 36+ messages in thread
From: Wichert Akkerman @ 2003-10-21 12:59 UTC (permalink / raw)
To: linux-kernel; +Cc: cpufreq
Previously Mattia Dongili wrote:
> Note: if you're subscribed to the cpufreq list you have a password to
> enter at the propmt :)
Why not open the archives to everyone? It is a bit silly to have to
subscribe to all kinds of list just to be able to get some general
information.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 10:52 ` Mattia Dongili
2003-10-21 12:59 ` Wichert Akkerman
@ 2003-10-21 15:36 ` Daniel Thor Kristjansson
2003-10-21 20:32 ` Dominik Brodowski
2003-10-21 19:23 ` Carl Thompson
2 siblings, 1 reply; 36+ messages in thread
From: Daniel Thor Kristjansson @ 2003-10-21 15:36 UTC (permalink / raw)
To: Mattia Dongili; +Cc: linux-kernel, cpufreq
The _user_ shouldn't set the cpu frequency hundred of times a second,
but a userland program should set the priorities. If you are just
looking at CPU Temperature and the idle loop for setting your cpu
frequency then it's fine to do it in the kernel. But if you are looking
at dozens of factors and balancing them it is much safer to do so in
userland. CPUFreq has been rearchitectured to allow this type of thing,
you can have a governor in the kernel that sets CPU Frequency based on
load within limits specified by a userland program. ACPI can meantime
throttle the CPU if it gets too hot based on what the BIOS tells you or
based on what the user tells you if you have a broken BIOS that lets the
CPU die before it thinks it's too hot.
The user may know things the kernel doesn't such as "this laptop is
burning a hole in my pants." She might want to construct a policy that
doesn't minimize power consumption since she's plugged in, but gives the
CPU lots of juice at first when the idle goes down, but then backs off
if it detects a long running 100% utilization such as during a long
compile. This would maximize responsiveness in interactive settings but
still keep her lap comfortably cool when compiling mozilla. Putting the
complexity of policies specified by something like an XML file in the
kernel scares me, putting it in a userspace program that communicates
with a low level governor is a more comforting thought.
-- Daniel
On Tue, 21 Oct 2003, Mattia Dongili wrote:
]On Tue, Oct 21, 2003 at 12:17:37PM +0200, Wichert Akkerman wrote:
]> Previously Mattia Dongili wrote:
]> > I remember Linus forcing a kernel only policy management:
]> > http://www.linux.org.uk/mailman/private/cpufreq/2002-August/000865.html
]>
]> That archive is password-protected..
]
]<QUOTE>
]
]On Wed, 28 Aug 2002, Dominik Brodowski wrote:
]>
]> The following patches add CPU frequency and volatage scaling
]> support (Intel SpeedStep, AMD PowerNow, etc.) to kernel 2.5.32
]
]The thing is, this interface appears fundamentally broken with respect to
]CPU's that change their frequency on the fly. I happen to know one such
]CPU rather well myself.
]
]What is this interface supposed to do about a CPU that can change its
]frequency dynamically several hundred times a second? Having the OS
]control it simply isn't an option - the overhead of the control is _way_
]more than is acceptable at that level.
]
]In short, this interface is too broken to be called generic.
]
]A quote from Peter Anvin:
]
] "What is worse is that the interface is, in my opinion, fundamentally
] broken for *ALL* CPUs. It doesn't present a policy interface to the
] kernel, instead it presents a frequency-setting interface and expect
] the policy to be done in userspace. The kernel is the only part of the
] system which has sufficient information (idle times of all CPUs, for
] example) to do a decent job managing the CPU frequency efficiently.
] On Transmeta CPUs this policy should simply be passed down to CMS, of
] course; on other CPUs the kernel needs to manage it."
]
]In other words: there is no valid way that a _user_ can set the policy
]right now: the user can set the frequency, but since any sane policy
]depends on how busy the CPU is, the user isn't even, the right person to
]_do_ that, since the user doesn't _know_.
]
]Also note that policy is not just about how busy the CPU is, but also
]about how _hot_ the CPU is. Again, a user-mode application (that maybe
]polls the situation every minute or so), simply _cannot_ handle this
]situation. You need to have the ability to poll the CPU tens of times a
]second to react to heat events, and clearly user mode cannot do that
]without impacting performance in a big way.
]
]The interface needs to be improved upon. It is simply _not_ valid to say
]"run at this speed" as the primary policy.
]
] Linus
]
]</QUOTE>
]
]anyway there has been a full discussion regarding this issue.
]
]The result has been a major redesing of the cpufreq interface in
]accordance to Linus' statements
]
]Note: if you're subscribed to the cpufreq list you have a password to
]enter at the propmt :)
]
]ciao
]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 15:36 ` Daniel Thor Kristjansson
@ 2003-10-21 20:32 ` Dominik Brodowski
0 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-21 20:32 UTC (permalink / raw)
To: danielk; +Cc: Mattia Dongili, linux-kernel, cpufreq
On Tue, Oct 21, 2003 at 11:36:56AM -0400, Daniel Thor Kristjansson wrote:
>
> The _user_ shouldn't set the cpu frequency hundred of times a second,
> but a userland program should set the priorities. If you are just
> looking at CPU Temperature and the idle loop for setting your cpu
> frequency then it's fine to do it in the kernel. But if you are looking
> at dozens of factors and balancing them it is much safer to do so in
> userland.
Wrong. Passing "events" or "information" to cpufreq governors by
cpufreq_governor() is much easier, cheaper, and more reliable.
> CPUFreq has been rearchitectured to allow this type of thing,
> you can have a governor in the kernel that sets CPU Frequency based on
> load within limits specified by a userland program.
Wrong again. CPUfreq has been rearchitectured to do this kernel-space.
The userspace governor allows setting to specific frequencies by the user
["I _want_ 500 MHz and nothing else!"], and it offers backwards
compatibility for the first-era cpufreq interface [LART project etc.].
> ACPI can meantime throttle the CPU if it gets too hot
However, frequency scaling is much more efficient on lowering the CPU heat,
too.
> The user may know things the kernel doesn't such as "this laptop is
> burning a hole in my pants." She might want to construct a policy that
> doesn't minimize power consumption since she's plugged in, but gives the
> CPU lots of juice at first when the idle goes down, but then backs off
> if it detects a long running 100% utilization such as during a long
> compile.
Yes indeed. She wants to set a cpufreq policy which suits of her needs:
it consists of a
- minimum frequency => not too low [she's plugged in]
- maximum frequency => 100%
- cpufreq governor => some kind of yet-to-be-written
dynamic cpufreq governor with
temperature or long-term-statistic
knowledge.
_I_ wouldn't want to run this governor, though -- I want kernel compiles to
complete as fast as possible. So, we need different in-kernel governors.
> This would maximize responsiveness in interactive settings but
> still keep her lap comfortably cool when compiling mozilla. Putting the
> complexity of policies specified by something like an XML file in the
> kernel scares me, putting it in a userspace program that communicates
> with a low level governor is a more comforting thought.
Well, the thing one of the cpufreq userspace programs does is really fine:
based on low-frequency events [power plug-in, running specific programs,
etc.] different cpufreq policies [see above] are selected. No XML file
necessary.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-21 20:32 ` Dominik Brodowski
0 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-21 20:32 UTC (permalink / raw)
To: danielk; +Cc: cpufreq, linux-kernel, Mattia Dongili
On Tue, Oct 21, 2003 at 11:36:56AM -0400, Daniel Thor Kristjansson wrote:
>
> The _user_ shouldn't set the cpu frequency hundred of times a second,
> but a userland program should set the priorities. If you are just
> looking at CPU Temperature and the idle loop for setting your cpu
> frequency then it's fine to do it in the kernel. But if you are looking
> at dozens of factors and balancing them it is much safer to do so in
> userland.
Wrong. Passing "events" or "information" to cpufreq governors by
cpufreq_governor() is much easier, cheaper, and more reliable.
> CPUFreq has been rearchitectured to allow this type of thing,
> you can have a governor in the kernel that sets CPU Frequency based on
> load within limits specified by a userland program.
Wrong again. CPUfreq has been rearchitectured to do this kernel-space.
The userspace governor allows setting to specific frequencies by the user
["I _want_ 500 MHz and nothing else!"], and it offers backwards
compatibility for the first-era cpufreq interface [LART project etc.].
> ACPI can meantime throttle the CPU if it gets too hot
However, frequency scaling is much more efficient on lowering the CPU heat,
too.
> The user may know things the kernel doesn't such as "this laptop is
> burning a hole in my pants." She might want to construct a policy that
> doesn't minimize power consumption since she's plugged in, but gives the
> CPU lots of juice at first when the idle goes down, but then backs off
> if it detects a long running 100% utilization such as during a long
> compile.
Yes indeed. She wants to set a cpufreq policy which suits of her needs:
it consists of a
- minimum frequency => not too low [she's plugged in]
- maximum frequency => 100%
- cpufreq governor => some kind of yet-to-be-written
dynamic cpufreq governor with
temperature or long-term-statistic
knowledge.
_I_ wouldn't want to run this governor, though -- I want kernel compiles to
complete as fast as possible. So, we need different in-kernel governors.
> This would maximize responsiveness in interactive settings but
> still keep her lap comfortably cool when compiling mozilla. Putting the
> complexity of policies specified by something like an XML file in the
> kernel scares me, putting it in a userspace program that communicates
> with a low level governor is a more comforting thought.
Well, the thing one of the cpufreq userspace programs does is really fine:
based on low-frequency events [power plug-in, running specific programs,
etc.] different cpufreq policies [see above] are selected. No XML file
necessary.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 20:32 ` Dominik Brodowski
@ 2003-10-22 15:48 ` Daniel Thor Kristjansson
-1 siblings, 0 replies; 36+ messages in thread
From: Daniel Thor Kristjansson @ 2003-10-22 15:48 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: danielk, cpufreq, linux-kernel, Mattia Dongili
]> The _user_ shouldn't set the cpu frequency hundred of times a second,
]> but a userland program should set the priorities. If you are just
]Wrong. Passing "events" or "information" to cpufreq governors by
]cpufreq_governor() is much easier, cheaper, and more reliable.
I think we may actually agree, but I may be wrong.
I have no problem with a governor setting the frequency and voltage
based on idle or temperature measurements only it can see efficiently.
But I think you still want more complex things to be decided in userland
which is more forgiving to programmer error. For instance this patch
does not allow you to tailor the polling frequency, if someone wrote a
such a governor that took battery into account my Vaio FXA53 would come
to a grinding halt as checking the battery through ACPI stops the
machine cold for about 200 ms. There is no need to poll the battery very
often, but someone with a fast battery check might do so simply out of
convenience.
]> CPUFreq has been rearchitectured to allow this type of thing,
]> you can have a governor in the kernel that sets CPU Frequency based on
]> load within limits specified by a userland program.
]Wrong again. CPUfreq has been rearchitectured to do this kernel-space.
]The userspace governor allows setting to specific frequencies by the user
]["I _want_ 500 MHz and nothing else!"], and it offers backwards
]compatibility for the first-era cpufreq interface [LART project etc.].
No, you can set a min and max frequency that the governor is allowed to
move within. This can be done by a userspace program through the /sys
interface. You can also use the "userspace" governor, but that's not
what I'm recommending.
]> ACPI can meantime throttle the CPU if it gets too hot
]However, frequency scaling is much more efficient on lowering the CPU heat,
]too.
Sure, a governor that does goes to the minimum frequency it's userland
governor has told it it has available to cool the CPU is a good thing.
Or, even below that if the CPU is near critical. If the CPU gets that
hot there is something wrong with the userland policy. Until this is
written, ACPI can act as a backup system to keep the CPU from burning
up.
]> The user may know things the kernel doesn't such as "this laptop is
]> burning a hole in my pants." She might want to construct a policy that
]Yes indeed. She wants to set a cpufreq policy which suits of her needs:
]it consists of a
]- minimum frequency => not too low [she's plugged in]
]- maximum frequency => 100%
]- cpufreq governor => some kind of yet-to-be-written
] dynamic cpufreq governor with
] temperature or long-term-statistic
] knowledge.
Why not a sensible governor in the kernel and a userland governor that
sets the minimum and maximum for desired effect?
]_I_ wouldn't want to run this governor, though -- I want kernel compiles to
]complete as fast as possible. So, we need different in-kernel governors.
I think a governor could keep the CPU running at 100% for long enough to
finish a kernel compile while still slowing down for a really long
compile like KDE, Mozilla, etc. It might however be too complex for me
to feel comfortable with it in the kernel.
]Well, the thing one of the cpufreq userspace programs does is really fine:
]based on low-frequency events [power plug-in, running specific programs,
]etc.] different cpufreq policies [see above] are selected. No XML file
]necessary.
Yes, the userspace program can just switch from performance, to
something in between w/min/max, to powersave. My arguement is just
against making the "something in between" too complex, by for
instance taking the low-frequency events into account.
-- Daniel
<<McCain was held in a bamboo cage and poked at with sticks for years.
That's the kind of guy who should be in the White House.>> -- Anon.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-22 15:48 ` Daniel Thor Kristjansson
0 siblings, 0 replies; 36+ messages in thread
From: Daniel Thor Kristjansson @ 2003-10-22 15:48 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: danielk, Mattia Dongili, cpufreq, linux-kernel
]> The _user_ shouldn't set the cpu frequency hundred of times a second,
]> but a userland program should set the priorities. If you are just
]Wrong. Passing "events" or "information" to cpufreq governors by
]cpufreq_governor() is much easier, cheaper, and more reliable.
I think we may actually agree, but I may be wrong.
I have no problem with a governor setting the frequency and voltage
based on idle or temperature measurements only it can see efficiently.
But I think you still want more complex things to be decided in userland
which is more forgiving to programmer error. For instance this patch
does not allow you to tailor the polling frequency, if someone wrote a
such a governor that took battery into account my Vaio FXA53 would come
to a grinding halt as checking the battery through ACPI stops the
machine cold for about 200 ms. There is no need to poll the battery very
often, but someone with a fast battery check might do so simply out of
convenience.
]> CPUFreq has been rearchitectured to allow this type of thing,
]> you can have a governor in the kernel that sets CPU Frequency based on
]> load within limits specified by a userland program.
]Wrong again. CPUfreq has been rearchitectured to do this kernel-space.
]The userspace governor allows setting to specific frequencies by the user
]["I _want_ 500 MHz and nothing else!"], and it offers backwards
]compatibility for the first-era cpufreq interface [LART project etc.].
No, you can set a min and max frequency that the governor is allowed to
move within. This can be done by a userspace program through the /sys
interface. You can also use the "userspace" governor, but that's not
what I'm recommending.
]> ACPI can meantime throttle the CPU if it gets too hot
]However, frequency scaling is much more efficient on lowering the CPU heat,
]too.
Sure, a governor that does goes to the minimum frequency it's userland
governor has told it it has available to cool the CPU is a good thing.
Or, even below that if the CPU is near critical. If the CPU gets that
hot there is something wrong with the userland policy. Until this is
written, ACPI can act as a backup system to keep the CPU from burning
up.
]> The user may know things the kernel doesn't such as "this laptop is
]> burning a hole in my pants." She might want to construct a policy that
]Yes indeed. She wants to set a cpufreq policy which suits of her needs:
]it consists of a
]- minimum frequency => not too low [she's plugged in]
]- maximum frequency => 100%
]- cpufreq governor => some kind of yet-to-be-written
] dynamic cpufreq governor with
] temperature or long-term-statistic
] knowledge.
Why not a sensible governor in the kernel and a userland governor that
sets the minimum and maximum for desired effect?
]_I_ wouldn't want to run this governor, though -- I want kernel compiles to
]complete as fast as possible. So, we need different in-kernel governors.
I think a governor could keep the CPU running at 100% for long enough to
finish a kernel compile while still slowing down for a really long
compile like KDE, Mozilla, etc. It might however be too complex for me
to feel comfortable with it in the kernel.
]Well, the thing one of the cpufreq userspace programs does is really fine:
]based on low-frequency events [power plug-in, running specific programs,
]etc.] different cpufreq policies [see above] are selected. No XML file
]necessary.
Yes, the userspace program can just switch from performance, to
something in between w/min/max, to powersave. My arguement is just
against making the "something in between" too complex, by for
instance taking the low-frequency events into account.
-- Daniel
<<McCain was held in a bamboo cage and poked at with sticks for years.
That's the kind of guy who should be in the White House.>> -- Anon.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 20:32 ` Dominik Brodowski
@ 2003-10-23 14:32 ` Pavel Machek
-1 siblings, 0 replies; 36+ messages in thread
From: Pavel Machek @ 2003-10-23 14:32 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: danielk, Mattia Dongili, linux-kernel, cpufreq
Hi!
> Yes indeed. She wants to set a cpufreq policy which suits of her needs:
> it consists of a
> - minimum frequency => not too low [she's plugged in]
I just hope minimum frequency is not going to be
honoured in case of overheat.
Issue is what happens if user specifies range containing no
valid frequency. Kernel currently uses next _higher_
frequency, but going for next lower one seems to be
important (burning cpus, exploding batteries, ...)
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-23 14:32 ` Pavel Machek
0 siblings, 0 replies; 36+ messages in thread
From: Pavel Machek @ 2003-10-23 14:32 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: danielk, cpufreq, linux-kernel, Mattia Dongili
Hi!
> Yes indeed. She wants to set a cpufreq policy which suits of her needs:
> it consists of a
> - minimum frequency => not too low [she's plugged in]
I just hope minimum frequency is not going to be
honoured in case of overheat.
Issue is what happens if user specifies range containing no
valid frequency. Kernel currently uses next _higher_
frequency, but going for next lower one seems to be
important (burning cpus, exploding batteries, ...)
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-23 14:32 ` Pavel Machek
@ 2003-10-24 18:22 ` Dominik Brodowski
-1 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-24 18:22 UTC (permalink / raw)
To: Pavel Machek; +Cc: danielk, cpufreq, linux-kernel, Mattia Dongili
On Thu, Oct 23, 2003 at 04:32:43PM +0200, Pavel Machek wrote:
> Hi!
>
> > Yes indeed. She wants to set a cpufreq policy which suits of her needs:
> > it consists of a
> > - minimum frequency => not too low [she's plugged in]
>
> I just hope minimum frequency is not going to be
> honoured in case of overheat.
>
> Issue is what happens if user specifies range containing no
> valid frequency. Kernel currently uses next _higher_
> frequency, but going for next lower one seems to be
> important (burning cpus, exploding batteries, ...)
Yes, that's one bug my acpi patchset addresses.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-24 18:22 ` Dominik Brodowski
0 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-24 18:22 UTC (permalink / raw)
To: Pavel Machek; +Cc: danielk, Mattia Dongili, cpufreq, linux-kernel
On Thu, Oct 23, 2003 at 04:32:43PM +0200, Pavel Machek wrote:
> Hi!
>
> > Yes indeed. She wants to set a cpufreq policy which suits of her needs:
> > it consists of a
> > - minimum frequency => not too low [she's plugged in]
>
> I just hope minimum frequency is not going to be
> honoured in case of overheat.
>
> Issue is what happens if user specifies range containing no
> valid frequency. Kernel currently uses next _higher_
> frequency, but going for next lower one seems to be
> important (burning cpus, exploding batteries, ...)
Yes, that's one bug my acpi patchset addresses.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 10:52 ` Mattia Dongili
2003-10-21 12:59 ` Wichert Akkerman
2003-10-21 15:36 ` Daniel Thor Kristjansson
@ 2003-10-21 19:23 ` Carl Thompson
2003-10-21 20:37 ` Dominik Brodowski
2 siblings, 1 reply; 36+ messages in thread
From: Carl Thompson @ 2003-10-21 19:23 UTC (permalink / raw)
To: dongili; +Cc: linux-kernel, cpufreq
I know Linus wrote this but...
> ...
> A quote from Peter Anvin:
>
> "What is worse is that the interface is, in my opinion, fundamentally
> broken for *ALL* CPUs. It doesn't present a policy interface to the
> kernel, instead it presents a frequency-setting interface and expect
> the policy to be done in userspace. The kernel is the only part of
> the
> system which has sufficient information (idle times of all CPUs, for
> example) to do a decent job managing the CPU frequency efficiently.
> On Transmeta CPUs this policy should simply be passed down to CMS, of
> course; on other CPUs the kernel needs to manage it."
>
> In other words: there is no valid way that a _user_ can set the policy
> right now: the user can set the frequency, but since any sane policy
> depends on how busy the CPU is, the user isn't even, the right person to
> _do_ that, since the user doesn't _know_.
But userspace _can_ know the idle statistics for each CPU. It's easily read
from /proc/stat.
> Also note that policy is not just about how busy the CPU is, but also
> about how _hot_ the CPU is. Again, a user-mode application (that maybe
> polls the situation every minute or so), simply _cannot_ handle this
> situation. You need to have the ability to poll the CPU tens of times a
> second to react to heat events, and clearly user mode cannot do that
> without impacting performance in a big way.
Well, my "cpuspeed" daemon has been doing exactly this without problems for
the better part of a year on many laptops tested by me and others. Polling
the CPU temperature every second or two seems quite sufficient to head off
any heat related problems (including on problematic systems like the Sony
Vaio FXA series). It doesn't appear to necessary to poll faster on current
hardware even with severe load spikes. (Obviously, hardware failures in
the cooling system are another matter but the CPUs internal protection
should handle that.)
My cpuspeed daemon uses a negligable amount of CPU so it doesn't seem like a
terrible solution...
(As mentioned previously, CPUs that change their own speed are a separate
issue.)
Carl Thompson
> ...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 19:23 ` Carl Thompson
@ 2003-10-21 20:37 ` Dominik Brodowski
0 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-21 20:37 UTC (permalink / raw)
To: Carl Thompson; +Cc: dongili, linux-kernel, cpufreq
On Tue, Oct 21, 2003 at 12:23:18PM -0700, Carl Thompson wrote:
> > In other words: there is no valid way that a _user_ can set the policy
> > right now: the user can set the frequency, but since any sane policy
> > depends on how busy the CPU is, the user isn't even, the right person to
> > _do_ that, since the user doesn't _know_.
>
> But userspace _can_ know the idle statistics for each CPU. It's easily read
> from /proc/stat.
Well, /proc/stat, and kstat_cpu is very inaccurate. There's a project going
on to get better statistics for usage by cpufreq governors. And you really
don't want to export all sorts of statistics every, or every tenth timer
tick to userspace. But if it's done in kernel-space, and if it's done right,
it may cost really few percentage points of performance.
Even though the governor proposed by Venkatesh may be done as well in
userspace [which I doubt], it's only one of several possible dynamic
cpufreq governors, most of which will be much faster, leaner and meaner in
kernel space.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-21 20:37 ` Dominik Brodowski
0 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-21 20:37 UTC (permalink / raw)
To: Carl Thompson; +Cc: cpufreq, linux-kernel, dongili
On Tue, Oct 21, 2003 at 12:23:18PM -0700, Carl Thompson wrote:
> > In other words: there is no valid way that a _user_ can set the policy
> > right now: the user can set the frequency, but since any sane policy
> > depends on how busy the CPU is, the user isn't even, the right person to
> > _do_ that, since the user doesn't _know_.
>
> But userspace _can_ know the idle statistics for each CPU. It's easily read
> from /proc/stat.
Well, /proc/stat, and kstat_cpu is very inaccurate. There's a project going
on to get better statistics for usage by cpufreq governors. And you really
don't want to export all sorts of statistics every, or every tenth timer
tick to userspace. But if it's done in kernel-space, and if it's done right,
it may cost really few percentage points of performance.
Even though the governor proposed by Venkatesh may be done as well in
userspace [which I doubt], it's only one of several possible dynamic
cpufreq governors, most of which will be much faster, leaner and meaner in
kernel space.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 8:38 ` Arjan van de Ven
(?)
(?)
@ 2003-10-21 20:44 ` Dominik Brodowski
-1 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-21 20:44 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Mallick, Asit K, linux-acpi, cpufreq, Nakajima, Jun, Pallipadi,
Venkatesh
On Tue, Oct 21, 2003 at 10:38:53AM +0200, Arjan van de Ven wrote:
> Note that I'm not totally against doing some of this in the kernel; I
> can well see the point of say, detecting an IRQ overload and based on
> that, go to max speed in the kernel because it's a situation where
> userspace doesn't even run; but the patch as is doesn't do any such
> advanced things...
Indeed, this driver doesn't do anything like that. However, I want to point
out two [of more] reasons why this is the right thing to do:
1.) I'm aware of one embedded system running linux which only has two
userspace programs - busybox and cardmgr. All other stuff is handled
in the kernel. An effort to remove the dependency on cardmgr is going on
[ <linux-pcmcia@lists.infradead.org> ]. If this embedded system was
supporting cpufreq, would you want to do dynamic scaling in the kernel, or
in userspace?
2.) It's a starting point for more advanced governors which really cannot be
done in userspace as this would be much too expensive. Having to choose
between different kernel and different userspace governors seems a bit
complicated for me. The _cost_ of doing this specific governor in the kernel
is near zero.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 2:56 ` Pallipadi, Venkatesh
(?)
(?)
@ 2003-10-21 20:59 ` Dominik Brodowski
-1 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-21 20:59 UTC (permalink / raw)
To: Pallipadi, Venkatesh; +Cc: Mallick, Asit K, cpufreq, Nakajima, Jun, linux-acpi
A few comments on this patch.
> + * Copyright (C) 2001 Russell King
> + * (C) 2002 - 2003 Dominik Brodowski <linux@brodo.de>
As nothing in this driver is from me, please remove my copyright
> + * $Id:$
No need for an ID tag -- you can remove that as well.
> +#define DBS_RATE (HZ/4) /* timer rate is 250ms */
> +#define LOW_LATENCY_FREQUENCY_CHANGE_LIMIT 100 /* in uS */
That's really low. latency_timer is in 10^(-9) s == ns [see cpufreq.h], so I
think you're missing a factor of 1000 here -- but maybe some drivers miss a
factor of 1000, too...
> +static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
> + unsigned int event)
> +{
> + unsigned int cpu = policy->cpu;
> +
> + switch (event) {
> + case CPUFREQ_GOV_START:
> + if ((!cpu_online(cpu)) || (!try_module_get(THIS_MODULE)) || !policy->cur)
> + return -EINVAL;
You needn't worry about try_module_get()/put_module() and friends. That's handled by
the cpufreq core already.
Dominik
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-21 2:56 ` Pallipadi, Venkatesh
@ 2003-10-23 14:17 ` Pavel Machek
-1 siblings, 0 replies; 36+ messages in thread
From: Pavel Machek @ 2003-10-23 14:17 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: cpufreq, linux-kernel, linux-acpi, Nakajima, Jun, Mallick,
Asit K, Dominik Brodowski
Hi!
> Patch 3/3: New dynamic cpufreq driver (called
> DemandBasedSwitch driver), which periodically monitors CPU
> usage and changes the CPU frequency based on the demand.
>
> diffstat dbs3.patch
> drivers/cpufreq/Kconfig | 25 ++++
> drivers/cpufreq/Makefile | 1
> drivers/cpufreq/cpufreq_dbs.c | 214
>
Could you name it cpufreq_demand? We have enough
TLAs as is.
Pavwl
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-23 14:17 ` Pavel Machek
0 siblings, 0 replies; 36+ messages in thread
From: Pavel Machek @ 2003-10-23 14:17 UTC (permalink / raw)
To: Pallipadi, Venkatesh
Cc: cpufreq, Nakajima, Jun, linux-acpi, Mallick, Asit K,
linux-kernel, Dominik Brodowski
Hi!
> Patch 3/3: New dynamic cpufreq driver (called
> DemandBasedSwitch driver), which periodically monitors CPU
> usage and changes the CPU frequency based on the demand.
>
> diffstat dbs3.patch
> drivers/cpufreq/Kconfig | 25 ++++
> drivers/cpufreq/Makefile | 1
> drivers/cpufreq/cpufreq_dbs.c | 214
>
Could you name it cpufreq_demand? We have enough
TLAs as is.
Pavwl
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-23 20:47 ` Moore, Robert
0 siblings, 0 replies; 36+ messages in thread
From: Moore, Robert @ 2003-10-23 20:47 UTC (permalink / raw)
To: Pavel Machek, Pallipadi, Venkatesh
Cc: cpufreq, linux-kernel, linux-acpi, Nakajima, Jun, Mallick,
Asit K, Dominik Brodowski
I would vote for "cpufreq_dynamic"
Bob
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Thursday, October 23, 2003 7:17 AM
To: Pallipadi, Venkatesh
Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org; linux-acpi;
Nakajima, Jun; Mallick, Asit K; Dominik Brodowski
Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
P-state driver
Hi!
> Patch 3/3: New dynamic cpufreq driver (called
> DemandBasedSwitch driver), which periodically monitors CPU
> usage and changes the CPU frequency based on the demand.
>
> diffstat dbs3.patch
> drivers/cpufreq/Kconfig | 25 ++++
> drivers/cpufreq/Makefile | 1
> drivers/cpufreq/cpufreq_dbs.c | 214
>
Could you name it cpufreq_demand? We have enough
TLAs as is.
Pavwl
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you
don't need...
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-23 20:47 ` Moore, Robert
0 siblings, 0 replies; 36+ messages in thread
From: Moore, Robert @ 2003-10-23 20:47 UTC (permalink / raw)
To: Pavel Machek, Pallipadi, Venkatesh
Cc: cpufreq, Nakajima, Jun, linux-acpi, Mallick, Asit K,
linux-kernel, Dominik Brodowski
I would vote for "cpufreq_dynamic"
Bob
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Thursday, October 23, 2003 7:17 AM
To: Pallipadi, Venkatesh
Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org; linux-acpi;
Nakajima, Jun; Mallick, Asit K; Dominik Brodowski
Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
P-state driver
Hi!
> Patch 3/3: New dynamic cpufreq driver (called
> DemandBasedSwitch driver), which periodically monitors CPU
> usage and changes the CPU frequency based on the demand.
>
> diffstat dbs3.patch
> drivers/cpufreq/Kconfig | 25 ++++
> drivers/cpufreq/Makefile | 1
> drivers/cpufreq/cpufreq_dbs.c | 214
>
Could you name it cpufreq_demand? We have enough
TLAs as is.
Pavwl
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you
don't need...
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-23 21:50 ` Nakajima, Jun
0 siblings, 0 replies; 36+ messages in thread
From: Nakajima, Jun @ 2003-10-23 21:50 UTC (permalink / raw)
To: Moore, Robert, Pavel Machek, Pallipadi, Venkatesh
Cc: cpufreq, linux-kernel, linux-acpi, Mallick, Asit K, Dominik Brodowski
Me too, because it would be consistent with the other ones; i.e. how the
user perceives them.
Jun
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Thursday, October 23, 2003 1:48 PM
> To: Pavel Machek; Pallipadi, Venkatesh
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org;
linux-acpi;
> Nakajima, Jun; Mallick, Asit K; Dominik Brodowski
> Subject: RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
P-
> state driver
>
>
> I would vote for "cpufreq_dynamic"
>
> Bob
>
>
> -----Original Message-----
> From: Pavel Machek [mailto:pavel@ucw.cz]
> Sent: Thursday, October 23, 2003 7:17 AM
> To: Pallipadi, Venkatesh
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org;
linux-acpi;
> Nakajima, Jun; Mallick, Asit K; Dominik Brodowski
> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
> P-state driver
>
> Hi!
>
> > Patch 3/3: New dynamic cpufreq driver (called
> > DemandBasedSwitch driver), which periodically monitors CPU
> > usage and changes the CPU frequency based on the demand.
> >
> > diffstat dbs3.patch
> > drivers/cpufreq/Kconfig | 25 ++++
> > drivers/cpufreq/Makefile | 1
> > drivers/cpufreq/cpufreq_dbs.c | 214
> >
> Could you name it cpufreq_demand? We have enough
> TLAs as is.
> Pavwl
>
>
> --
> Pavel
> Written on sharp zaurus, because my Velo1 broke. If you have Velo you
> don't need...
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-23 21:50 ` Nakajima, Jun
0 siblings, 0 replies; 36+ messages in thread
From: Nakajima, Jun @ 2003-10-23 21:50 UTC (permalink / raw)
To: Moore, Robert, Pavel Machek, Pallipadi, Venkatesh
Cc: Mallick, Asit K, Dominik Brodowski, linux-acpi, cpufreq, linux-kernel
Me too, because it would be consistent with the other ones; i.e. how the
user perceives them.
Jun
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Thursday, October 23, 2003 1:48 PM
> To: Pavel Machek; Pallipadi, Venkatesh
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org;
linux-acpi;
> Nakajima, Jun; Mallick, Asit K; Dominik Brodowski
> Subject: RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
P-
> state driver
>
>
> I would vote for "cpufreq_dynamic"
>
> Bob
>
>
> -----Original Message-----
> From: Pavel Machek [mailto:pavel@ucw.cz]
> Sent: Thursday, October 23, 2003 7:17 AM
> To: Pallipadi, Venkatesh
> Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org;
linux-acpi;
> Nakajima, Jun; Mallick, Asit K; Dominik Brodowski
> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI
> P-state driver
>
> Hi!
>
> > Patch 3/3: New dynamic cpufreq driver (called
> > DemandBasedSwitch driver), which periodically monitors CPU
> > usage and changes the CPU frequency based on the demand.
> >
> > diffstat dbs3.patch
> > drivers/cpufreq/Kconfig | 25 ++++
> > drivers/cpufreq/Makefile | 1
> > drivers/cpufreq/cpufreq_dbs.c | 214
> >
> Could you name it cpufreq_demand? We have enough
> TLAs as is.
> Pavwl
>
>
> --
> Pavel
> Written on sharp zaurus, because my Velo1 broke. If you have Velo you
> don't need...
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-23 21:50 ` Nakajima, Jun
@ 2003-10-24 18:38 ` Dominik Brodowski
-1 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-24 18:38 UTC (permalink / raw)
To: Nakajima, Jun, Moore, Robert, Pavel Machek
Cc: Pallipadi, Venkatesh, Mallick, Asit K, linux-acpi, cpufreq, linux-kernel
Vetoed.
cpufreq_dynamic is too generic, there are different approaches == different
governors in the work which are all "dynamic".
Dominik
On Thu, Oct 23, 2003 at 02:50:06PM -0700, Nakajima, Jun wrote:
> Me too, because it would be consistent with the other ones; i.e. how the
> user perceives them.
On Thu, Oct 23, 2003 at 01:47:49PM -0700, Moore, Robert wrote:
>
> I would vote for "cpufreq_dynamic"
>
> Bob
On Thu, Oct 23, 2003 at 04:17:04PM +0200, Pavel Machek wrote:
> Could you name it cpufreq_demand? We have enough
> TLAs as is.
> Pavwl
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-24 18:38 ` Dominik Brodowski
0 siblings, 0 replies; 36+ messages in thread
From: Dominik Brodowski @ 2003-10-24 18:38 UTC (permalink / raw)
To: Nakajima, Jun, Moore, Robert, Pavel Machek
Cc: Mallick, Asit K, linux-kernel, linux-acpi, cpufreq, Pallipadi, Venkatesh
Vetoed.
cpufreq_dynamic is too generic, there are different approaches == different
governors in the work which are all "dynamic".
Dominik
On Thu, Oct 23, 2003 at 02:50:06PM -0700, Nakajima, Jun wrote:
> Me too, because it would be consistent with the other ones; i.e. how the
> user perceives them.
On Thu, Oct 23, 2003 at 01:47:49PM -0700, Moore, Robert wrote:
>
> I would vote for "cpufreq_dynamic"
>
> Bob
On Thu, Oct 23, 2003 at 04:17:04PM +0200, Pavel Machek wrote:
> Could you name it cpufreq_demand? We have enough
> TLAs as is.
> Pavwl
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
2003-10-23 20:47 ` Moore, Robert
@ 2003-10-24 11:27 ` Ducrot Bruno
-1 siblings, 0 replies; 36+ messages in thread
From: Ducrot Bruno @ 2003-10-24 11:27 UTC (permalink / raw)
To: Moore, Robert
Cc: Pavel Machek, Pallipadi, Venkatesh, cpufreq, Nakajima, Jun,
linux-acpi, Mallick, Asit K, linux-kernel, Dominik Brodowski
On Thu, Oct 23, 2003 at 01:47:49PM -0700, Moore, Robert wrote:
>
> I would vote for "cpufreq_dynamic"
>
Name is too generic IMHO. There are a lot
of other ways to do dynamic switching.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-24 11:27 ` Ducrot Bruno
0 siblings, 0 replies; 36+ messages in thread
From: Ducrot Bruno @ 2003-10-24 11:27 UTC (permalink / raw)
To: Moore, Robert
Cc: cpufreq, Nakajima, Jun, linux-acpi, Mallick, Asit K,
Pavel Machek, Pallipadi, Venkatesh, linux-kernel,
Dominik Brodowski
On Thu, Oct 23, 2003 at 01:47:49PM -0700, Moore, Robert wrote:
>
> I would vote for "cpufreq_dynamic"
>
Name is too generic IMHO. There are a lot
of other ways to do dynamic switching.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-22 5:50 Pallipadi, Venkatesh
0 siblings, 0 replies; 36+ messages in thread
From: Pallipadi, Venkatesh @ 2003-10-22 5:50 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: Mallick, Asit K, cpufreq, Nakajima, Jun, linux-acpi
> -----Original Message-----
> From: Dominik Brodowski [mailto:linux@brodo.de]
>
> > +#define DBS_RATE (HZ/4) /* timer rate is 250ms */
> > +#define LOW_LATENCY_FREQUENCY_CHANGE_LIMIT 100 /* in uS */
> That's really low. latency_timer is in 10^(-9) s == ns [see
cpufreq.h], so I
> think you're missing a factor of 1000 here -- but maybe some drivers
miss a
> factor of 1000, too...
Yes. I got confused about this after seeing drivers using it as uS in
place of nS.
Will fix it. I will also look at the drivers and fix them.
Thanks,
-Venkatesh
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-24 18:52 ` Pallipadi, Venkatesh
0 siblings, 0 replies; 36+ messages in thread
From: Pallipadi, Venkatesh @ 2003-10-24 18:52 UTC (permalink / raw)
To: Dominik Brodowski, Nakajima, Jun, Moore, Robert, Pavel Machek
Cc: Mallick, Asit K, linux-acpi, cpufreq, linux-kernel
OK. I will stick 'demandbased' then.
-Venkatesh
> -----Original Message-----
> From: Dominik Brodowski [mailto:linux@brodo.de]
> Sent: Friday, October 24, 2003 11:39 AM
> To: Nakajima, Jun; Moore, Robert; Pavel Machek
> Cc: Pallipadi, Venkatesh; Mallick, Asit K; linux-acpi;
> cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates
> to ACPI P-state driver
>
>
> Vetoed.
>
> cpufreq_dynamic is too generic, there are different
> approaches == different
> governors in the work which are all "dynamic".
>
> Dominik
>
> On Thu, Oct 23, 2003 at 02:50:06PM -0700, Nakajima, Jun wrote:
> > Me too, because it would be consistent with the other ones;
> i.e. how the
> > user perceives them.
>
> On Thu, Oct 23, 2003 at 01:47:49PM -0700, Moore, Robert wrote:
> >
> > I would vote for "cpufreq_dynamic"
> >
> > Bob
>
> On Thu, Oct 23, 2003 at 04:17:04PM +0200, Pavel Machek wrote:
> > Could you name it cpufreq_demand? We have enough
> > TLAs as is.
> > Pavwl
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver
@ 2003-10-24 18:52 ` Pallipadi, Venkatesh
0 siblings, 0 replies; 36+ messages in thread
From: Pallipadi, Venkatesh @ 2003-10-24 18:52 UTC (permalink / raw)
To: Dominik Brodowski, Nakajima, Jun, Moore, Robert, Pavel Machek
Cc: Mallick, Asit K, linux-acpi, cpufreq, linux-kernel
OK. I will stick 'demandbased' then.
-Venkatesh
> -----Original Message-----
> From: Dominik Brodowski [mailto:linux@brodo.de]
> Sent: Friday, October 24, 2003 11:39 AM
> To: Nakajima, Jun; Moore, Robert; Pavel Machek
> Cc: Pallipadi, Venkatesh; Mallick, Asit K; linux-acpi;
> cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates
> to ACPI P-state driver
>
>
> Vetoed.
>
> cpufreq_dynamic is too generic, there are different
> approaches == different
> governors in the work which are all "dynamic".
>
> Dominik
>
> On Thu, Oct 23, 2003 at 02:50:06PM -0700, Nakajima, Jun wrote:
> > Me too, because it would be consistent with the other ones;
> i.e. how the
> > user perceives them.
>
> On Thu, Oct 23, 2003 at 01:47:49PM -0700, Moore, Robert wrote:
> >
> > I would vote for "cpufreq_dynamic"
> >
> > Bob
>
> On Thu, Oct 23, 2003 at 04:17:04PM +0200, Pavel Machek wrote:
> > Could you name it cpufreq_demand? We have enough
> > TLAs as is.
> > Pavwl
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2003-10-24 18:52 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-21 2:56 [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver Pallipadi, Venkatesh
2003-10-21 2:56 ` Pallipadi, Venkatesh
2003-10-21 8:38 ` Arjan van de Ven
2003-10-21 8:38 ` Arjan van de Ven
2003-10-21 9:59 ` Mattia Dongili
2003-10-21 9:59 ` Mattia Dongili
2003-10-21 10:17 ` Wichert Akkerman
2003-10-21 10:52 ` Mattia Dongili
2003-10-21 12:59 ` Wichert Akkerman
2003-10-21 15:36 ` Daniel Thor Kristjansson
2003-10-21 20:32 ` Dominik Brodowski
2003-10-21 20:32 ` Dominik Brodowski
2003-10-22 15:48 ` Daniel Thor Kristjansson
2003-10-22 15:48 ` Daniel Thor Kristjansson
2003-10-23 14:32 ` Pavel Machek
2003-10-23 14:32 ` Pavel Machek
2003-10-24 18:22 ` Dominik Brodowski
2003-10-24 18:22 ` Dominik Brodowski
2003-10-21 19:23 ` Carl Thompson
2003-10-21 20:37 ` Dominik Brodowski
2003-10-21 20:37 ` Dominik Brodowski
2003-10-21 20:44 ` Dominik Brodowski
2003-10-21 20:59 ` Dominik Brodowski
2003-10-23 14:17 ` Pavel Machek
2003-10-23 14:17 ` Pavel Machek
2003-10-23 20:47 ` Moore, Robert
2003-10-23 20:47 ` Moore, Robert
2003-10-23 21:50 ` Nakajima, Jun
2003-10-23 21:50 ` Nakajima, Jun
2003-10-24 18:38 ` Dominik Brodowski
2003-10-24 18:38 ` Dominik Brodowski
2003-10-24 11:27 ` Ducrot Bruno
2003-10-24 11:27 ` Ducrot Bruno
2003-10-22 5:50 Pallipadi, Venkatesh
2003-10-24 18:52 Pallipadi, Venkatesh
2003-10-24 18:52 ` Pallipadi, Venkatesh
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.