All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: governor implementations
@ 2004-04-30  0:37 Pallipadi, Venkatesh
  2004-04-30 13:27 ` Dave Jones
  0 siblings, 1 reply; 5+ messages in thread
From: Pallipadi, Venkatesh @ 2004-04-30  0:37 UTC (permalink / raw)
  To: Nickolai Zeldovich; +Cc: cpufreq

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]



Attached is a simple in-kernel CPU frequency governor. This has some
minor modification to the one that I had sent on this list, couple of
months back.

The main features:
- Checks CPU utilization periodically and increases the frequency to the
maximum whenever the utilization is high.
- Does similar check and tries to reduce the frequency when utilization
is low. But, by default, this check is done less frequently compared to
'increasing the frequency' checks.
- Default values of above frequencies depends on actual frequency
transition latency of the CPU.
- User can fine tune by using the parameters exported in /sys
- As things are done inside the kernel, this should have lesser overhead
compared to user daemon and reading CPU utilization information from
/proc or /sys. 

Patch is against latest 2.6 kernels. Try it and let me know your
feedback.

Thanks,
Venki

>-----Original Message-----
>From: cpufreq-bounces@www.linux.org.uk 
>[mailto:cpufreq-bounces@www.linux.org.uk] On Behalf Of 
>Nickolai Zeldovich
>Sent: Thursday, April 29, 2004 3:27 PM
>To: cpufreq@www.linux.org.uk
>Subject: governor implementations
>
>Has there been any effort on implementing governors other than the 3
>standard ones included in the kernel these days (powersave, performance
>and userspace), or adding hooks to the kernel scheduler to 
>interact with
>the userspace governor (that is, the userspace process, and 
>not the part
>of cpufreq code)?
>
>The problem I see is that currently there's no way to do fine-grained
>CPU speed adjustments to match the immediate user need.  
>Currently there
>are user-space daemons like cpuspeed that will poll your load 
>average at
>some intervals and adjust the CPU speed accordingly, but polling is not
>the right answer -- you can't poll fast enough to provide a smooth user
>experience without using up too much CPU for polling, I would guess.
>For example, Fedora Core 2 (test3) comes with cpuspeed that slows down
>my laptop from 1.6GHz to 600MHz.  That's great, but when I click on a
>menu in a Gnome application, it takes a long time to come up.  Even
>polling at 100ms, cpuspeed can't respond fast enough to this 
>user action
>to speed up the CPU and make the menu come up faster.
>
>On the other hand, implementing an in-kernel governor, or 
>exporting user
>callbacks like "the last tick was completely CPU bound, do something!",
>would allow fine-grained adjustment that would increase the 
>CPU speed as
>soon as the user started doing something, and would similarly 
>be able to
>quickly decrease it back down to save power.
>
>So in summary, it seems to me that much better power savings and user
>performance can be achieved by integrating cpuspeed much 
>closer with the
>scheduler -- I'd imagine people have thought about this already, so I'm
>looking for references to such work out there..
>
>-- kolya
>
>
>_______________________________________________
>Cpufreq mailing list
>Cpufreq@www.linux.org.uk
>http://www.linux.org.uk/mailman/listinfo/cpufreq
>

[-- Attachment #2: 05ondemand.patch --]
[-- Type: application/octet-stream, Size: 13694 bytes --]

diff -purN linux-2.6.5/drivers/cpufreq/cpufreq_ondemand.c linux-2.6.5-dbs/drivers/cpufreq/cpufreq_ondemand.c
--- linux-2.6.5/drivers/cpufreq/cpufreq_ondemand.c	1969-12-31 16:00:00.000000000 -0800
+++ linux-2.6.5-dbs/drivers/cpufreq/cpufreq_ondemand.c	2004-04-16 19:56:02.000000000 -0700
@@ -0,0 +1,424 @@
+/*
+ *  drivers/cpufreq/cpufreq_ondemand.c
+ *
+ *  Copyright (C)  2001 Russell King
+ *            (C)  2003 Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>.
+ *                      Jun Nakajima <jun.nakajima@intel.com>
+ *
+ * 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/config.h>
+#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>
+#include <linux/percpu.h>
+
+/*
+ * dbs is used in this file as a shortform for demandbased switching
+ * It helps to keep variable names smaller, simpler
+ */
+
+#define DEF_FREQUENCY_UP_THRESHOLD		(80)
+#define MIN_FREQUENCY_UP_THRESHOLD		(0)
+#define MAX_FREQUENCY_UP_THRESHOLD		(100)
+
+#define DEF_FREQUENCY_DOWN_THRESHOLD		(20)
+#define MIN_FREQUENCY_DOWN_THRESHOLD		(0)
+#define MAX_FREQUENCY_DOWN_THRESHOLD		(100)
+
+/* 
+ * The polling frequency of this governor depends on the capability of 
+ * the processor. Default polling frequency is 1000 times the transition
+ * latency of the processor. The governor will work on any processor with 
+ * transition latency <= 10mS, using appropriate sampling 
+ * rate.
+ * For CPUs with transition latency > 10mS (mostly drivers with CPUFREQ_ETERNAL)
+ * this governor will not work.
+ * All times here are in uS.
+ */
+static unsigned int 				def_sampling_rate;
+#define MIN_SAMPLING_RATE			(def_sampling_rate / 2)
+#define MAX_SAMPLING_RATE			(500 * def_sampling_rate)
+#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER	(1000)
+#define DEF_SAMPLING_DOWN_FACTOR		(10)
+#define TRANSITION_LATENCY_LIMIT		(10 * 1000)
+#define sampling_rate_in_HZ(x)			((x * HZ) / (1000 * 1000))
+
+static void do_dbs_timer(void *data);
+
+struct cpu_dbs_info_s {
+	struct cpufreq_policy 	*cur_policy;
+	unsigned int 		prev_cpu_idle_up;
+	unsigned int 		prev_cpu_idle_down;
+	unsigned int 		enable;
+};
+static DEFINE_PER_CPU(struct cpu_dbs_info_s, cpu_dbs_info);
+
+static unsigned int dbs_enable;	/* number of CPUs using this policy */
+
+static DECLARE_MUTEX 	(dbs_sem);
+static DECLARE_WORK	(dbs_work, do_dbs_timer, NULL);
+
+struct dbs_tuners {
+	unsigned int 		sampling_rate;
+	unsigned int		sampling_down_factor;
+	unsigned int		up_threshold;
+	unsigned int		down_threshold;
+};
+
+struct dbs_tuners dbs_tuners_ins = {
+	.up_threshold 		= DEF_FREQUENCY_UP_THRESHOLD,
+	.down_threshold 	= DEF_FREQUENCY_DOWN_THRESHOLD,
+	.sampling_down_factor 	= DEF_SAMPLING_DOWN_FACTOR,
+};
+
+/************************** sysfs interface ************************/
+static ssize_t show_current_freq(struct cpufreq_policy *policy, char *buf)
+{
+	return sprintf (buf, "%u\n", policy->cur);
+}
+
+static ssize_t show_sampling_rate_max(struct cpufreq_policy *policy, char *buf)
+{
+	return sprintf (buf, "%u\n", MAX_SAMPLING_RATE);
+}
+
+static ssize_t show_sampling_rate_min(struct cpufreq_policy *policy, char *buf)
+{
+	return sprintf (buf, "%u\n", MIN_SAMPLING_RATE);
+}
+
+#define define_one_ro(_name) 					\
+static struct freq_attr _name = { 				\
+	.attr = { .name = __stringify(_name), .mode = 0444 }, 	\
+	.show = show_##_name, 					\
+}
+
+define_one_ro(current_freq);
+define_one_ro(sampling_rate_max);
+define_one_ro(sampling_rate_min);
+
+/* cpufreq_ondemand Governor Tunables */
+#define show_one(file_name, object)					\
+static ssize_t show_##file_name						\
+(struct cpufreq_policy *unused, char *buf)				\
+{									\
+	return sprintf(buf, "%u\n", dbs_tuners_ins.object);		\
+}
+show_one(sampling_rate, sampling_rate);
+show_one(sampling_down_factor, sampling_down_factor);
+show_one(up_threshold, up_threshold);
+show_one(down_threshold, down_threshold);
+
+static ssize_t store_sampling_down_factor(struct cpufreq_policy *unused, 
+		const char *buf, size_t count)
+{
+	unsigned int input;
+	int ret;
+	ret = sscanf (buf, "%u", &input);
+	down(&dbs_sem);
+	if (ret != 1 )
+		goto out;
+
+	dbs_tuners_ins.sampling_down_factor = input;
+out:
+	up(&dbs_sem);
+	return count;
+}
+
+static ssize_t store_sampling_rate(struct cpufreq_policy *unused, 
+		const char *buf, size_t count)
+{
+	unsigned int input;
+	int ret;
+	ret = sscanf (buf, "%u", &input);
+	down(&dbs_sem);
+	if (ret != 1 || input > MAX_SAMPLING_RATE || input < MIN_SAMPLING_RATE)
+		goto out;
+
+	dbs_tuners_ins.sampling_rate = input;
+out:
+	up(&dbs_sem);
+	return count;
+}
+
+static ssize_t store_up_threshold(struct cpufreq_policy *unused, 
+		const char *buf, size_t count)
+{
+	unsigned int input;
+	int ret;
+	ret = sscanf (buf, "%u", &input);
+	down(&dbs_sem);
+	if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD || 
+			input < MIN_FREQUENCY_UP_THRESHOLD ||
+			input <= dbs_tuners_ins.down_threshold)
+		goto out;
+
+	dbs_tuners_ins.up_threshold = input;
+out:
+	up(&dbs_sem);
+	return count;
+}
+
+static ssize_t store_down_threshold(struct cpufreq_policy *unused, 
+		const char *buf, size_t count)
+{
+	unsigned int input;
+	int ret;
+	ret = sscanf (buf, "%u", &input);
+	down(&dbs_sem);
+	if (ret != 1 || input > MAX_FREQUENCY_DOWN_THRESHOLD || 
+			input < MIN_FREQUENCY_DOWN_THRESHOLD ||
+			input >= dbs_tuners_ins.up_threshold)
+		goto out;
+
+	dbs_tuners_ins.down_threshold = input;
+out:
+	up(&dbs_sem);
+	return count;
+}
+
+#define define_one_rw(_name) 					\
+static struct freq_attr _name = { 				\
+	.attr = { .name = __stringify(_name), .mode = 0644 }, 	\
+	.show = show_##_name, 					\
+	.store = store_##_name, 				\
+}
+
+define_one_rw(sampling_rate);
+define_one_rw(sampling_down_factor);
+define_one_rw(up_threshold);
+define_one_rw(down_threshold);
+
+static struct attribute * dbs_attributes[] = {
+	&current_freq.attr,
+	&sampling_rate_max.attr,
+	&sampling_rate_min.attr,
+	&sampling_rate.attr,
+	&sampling_down_factor.attr,
+	&up_threshold.attr,
+	&down_threshold.attr,
+	NULL
+};
+
+static struct attribute_group dbs_attr_group = {
+	.attrs = dbs_attributes,
+	.name = "ondemand",
+};
+
+/************************** sysfs end ************************/
+
+static void dbs_check_cpu(int cpu)
+{
+	unsigned int idle_ticks, up_idle_ticks, down_idle_ticks;
+	unsigned int freq_down_step;
+	unsigned int freq_down_sampling_rate;
+	static int down_skip[NR_CPUS];
+	struct cpu_dbs_info_s *this_dbs_info;
+
+	this_dbs_info = &per_cpu(cpu_dbs_info, cpu);
+	if (!this_dbs_info->enable)
+		return;
+
+	/* 
+	 * The default safe range is 20% to 80% 
+	 * Every sampling_rate, we check
+	 * 	- If current idle time is less than 20%, then we try to 
+	 * 	  increase frequency
+	 * Every sampling_rate*sampling_down_factor, we check
+	 * 	- If current idle time is more than 80%, then we try to
+	 * 	  decrease frequency
+	 *
+	 * Any frequency increase takes it to the maximum frequency. 
+	 * Frequency reduction happens at minimum steps of 
+	 * 5% of max_frequency 
+	 */
+	/* Check for frequency increase */
+	idle_ticks = kstat_cpu(cpu).cpustat.idle - 
+		this_dbs_info->prev_cpu_idle_up;
+	this_dbs_info->prev_cpu_idle_up = kstat_cpu(cpu).cpustat.idle;
+
+	up_idle_ticks = (100 - dbs_tuners_ins.up_threshold) *
+			sampling_rate_in_HZ(dbs_tuners_ins.sampling_rate) / 100;
+
+	if (idle_ticks < up_idle_ticks) {
+		__cpufreq_driver_target(this_dbs_info->cur_policy,
+			this_dbs_info->cur_policy->max, 
+			CPUFREQ_RELATION_H);
+		down_skip[cpu] = 0;
+		this_dbs_info->prev_cpu_idle_down = kstat_cpu(cpu).cpustat.idle;
+		return;
+	}
+
+	/* Check for frequency decrease */
+	down_skip[cpu]++;
+	if (down_skip[cpu] < dbs_tuners_ins.sampling_down_factor)
+		return;
+
+	idle_ticks = kstat_cpu(cpu).cpustat.idle - 
+		this_dbs_info->prev_cpu_idle_down;
+	down_skip[cpu] = 0;
+	this_dbs_info->prev_cpu_idle_down = kstat_cpu(cpu).cpustat.idle;
+
+	freq_down_sampling_rate = dbs_tuners_ins.sampling_rate *
+		dbs_tuners_ins.sampling_down_factor;
+	down_idle_ticks = (100 - dbs_tuners_ins.down_threshold) *
+			sampling_rate_in_HZ(freq_down_sampling_rate) / 100;
+
+	if (idle_ticks > down_idle_ticks ) {
+		freq_down_step = (5 * this_dbs_info->cur_policy->max) / 100;
+		__cpufreq_driver_target(this_dbs_info->cur_policy,
+			this_dbs_info->cur_policy->cur - freq_down_step, 
+			CPUFREQ_RELATION_H);
+		return;
+	}
+}
+
+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, 
+			sampling_rate_in_HZ(dbs_tuners_ins.sampling_rate));
+	up(&dbs_sem);
+} 
+
+static inline void dbs_timer_init(void)
+{
+	INIT_WORK(&dbs_work, do_dbs_timer, NULL);
+	schedule_work(&dbs_work);
+	return;
+}
+
+static inline void dbs_timer_exit(void)
+{
+	cancel_delayed_work(&dbs_work);
+	return;
+}
+
+static int cpufreq_governor_dbs(struct cpufreq_policy *policy,
+				   unsigned int event)
+{
+	unsigned int cpu = policy->cpu;
+	struct cpu_dbs_info_s *this_dbs_info;
+
+	this_dbs_info = &per_cpu(cpu_dbs_info, cpu);
+
+	switch (event) {
+	case CPUFREQ_GOV_START:
+		if ((!cpu_online(cpu)) || 
+		    (!policy->cur))
+			return -EINVAL;
+
+		if (policy->cpuinfo.transition_latency >
+				(TRANSITION_LATENCY_LIMIT * 1000))
+			return -EINVAL;
+		if (this_dbs_info->enable) /* Already enabled */
+			break;
+		 
+		down(&dbs_sem);
+		this_dbs_info->cur_policy = policy;
+		
+		this_dbs_info->prev_cpu_idle_up = 
+				kstat_cpu(cpu).cpustat.idle;
+		this_dbs_info->prev_cpu_idle_down = 
+				kstat_cpu(cpu).cpustat.idle;
+		this_dbs_info->enable = 1;
+		sysfs_create_group(&policy->kobj, &dbs_attr_group);
+		dbs_enable++;
+		/*
+		 * Start the timerschedule work, when this governor
+		 * is used for first time
+		 */
+		if (dbs_enable == 1) {
+			/* policy latency is in nS. Convert it to uS first */
+			def_sampling_rate = (policy->cpuinfo.transition_latency / 1000) *
+					DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
+			dbs_tuners_ins.sampling_rate = def_sampling_rate;
+
+			dbs_timer_init();
+		}
+		
+		up(&dbs_sem);
+		break;
+
+	case CPUFREQ_GOV_STOP:
+		down(&dbs_sem);
+		this_dbs_info->enable = 0;
+		sysfs_remove_group(&policy->kobj, &dbs_attr_group);
+		dbs_enable--;
+		/*
+		 * Stop the timerschedule work, when this governor
+		 * is used for first time
+		 */
+		if (dbs_enable == 0) 
+			dbs_timer_exit();
+		
+		up(&dbs_sem);
+
+		break;
+
+	case CPUFREQ_GOV_LIMITS:
+		down(&dbs_sem);
+		if (policy->max < this_dbs_info->cur_policy->cur)
+			__cpufreq_driver_target(
+					this_dbs_info->cur_policy,
+				       	policy->max, CPUFREQ_RELATION_H);
+		else if (policy->min > this_dbs_info->cur_policy->cur)
+			__cpufreq_driver_target(
+					this_dbs_info->cur_policy,
+				       	policy->min, CPUFREQ_RELATION_L);
+		up(&dbs_sem);
+		break;
+	}
+	return 0;
+}
+
+struct cpufreq_governor cpufreq_gov_dbs = {
+	.name		= "ondemand",
+	.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 ("'cpufreq_ondemand' - A dynamic cpufreq 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.5/drivers/cpufreq/Kconfig linux-2.6.5-dbs/drivers/cpufreq/Kconfig
--- linux-2.6.5/drivers/cpufreq/Kconfig	2004-04-15 14:02:20.000000000 -0700
+++ linux-2.6.5-dbs/drivers/cpufreq/Kconfig	2004-04-16 19:39:24.000000000 -0700
@@ -69,6 +69,21 @@ config CPU_FREQ_GOV_USERSPACE
 
 	  If in doubt, say Y.
 
+config CPU_FREQ_GOV_ONDEMAND
+	tristate "'ondemand' cpufreq policy governor"
+	depends on CPU_FREQ
+	help
+	  'ondemand' - This driver adds a dynamic cpufreq policy governor.
+	  The governor does a periodic polling and 
+	  changes frequency based on the CPU utilization.
+	  The support for this governor depends on CPU 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.5/drivers/cpufreq/Makefile linux-2.6.5-dbs/drivers/cpufreq/Makefile
--- linux-2.6.5/drivers/cpufreq/Makefile	2004-04-03 19:38:27.000000000 -0800
+++ linux-2.6.5-dbs/drivers/cpufreq/Makefile	2004-04-16 19:39:24.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_ONDEMAND)	+= cpufreq_ondemand.o
 
 # CPUfreq cross-arch helpers
 obj-$(CONFIG_CPU_FREQ_TABLE)		+= freq_table.o

[-- 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] 5+ messages in thread

* RE: governor implementations
       [not found] <E1BJM2v-0001tP-Nf@www.linux.org.uk>
@ 2004-04-30  1:46 ` David Tam
  2004-05-01 18:23   ` Bruno Ducrot
  0 siblings, 1 reply; 5+ messages in thread
From: David Tam @ 2004-04-30  1:46 UTC (permalink / raw)
  To: cpufreq; +Cc: wtsang, Catalin Drula

Hi.

We did some work along these lines for a grad course project in Dec 2003.
It was done using a development version of Linux kernel 2.6.
Unfortunately, we haven't had time to keep it up to date.
Hopefully, it only requires minor updates.

Here is a link to the web page.  You can check out our presentation slides,
final report, and other docs.
http://www.eecg.toronto.edu/~tamda/csc2228/

> Message: 3
> Date: Thu, 29 Apr 2004 17:37:52 -0700
> From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
> Subject: RE: governor implementations
> To: "Nickolai Zeldovich" <nickolai@cs.stanford.edu>
> Cc: cpufreq@www.linux.org.uk
> 
> Attached is a simple in-kernel CPU frequency governor. This has some
> minor modification to the one that I had sent on this list, couple of
> months back.
> 
> The main features:
> - Checks CPU utilization periodically and increases the frequency to the
> maximum whenever the utilization is high.
> - Does similar check and tries to reduce the frequency when utilization
> is low. But, by default, this check is done less frequently compared to
> 'increasing the frequency' checks.
> - Default values of above frequencies depends on actual frequency
> transition latency of the CPU.
> - User can fine tune by using the parameters exported in /sys
> - As things are done inside the kernel, this should have lesser overhead
> compared to user daemon and reading CPU utilization information from
> /proc or /sys. 
> 
> Patch is against latest 2.6 kernels. Try it and let me know your
> feedback.
> 
> >-----Original Message-----
> >From: cpufreq-bounces@www.linux.org.uk 
> >[mailto:cpufreq-bounces@www.linux.org.uk] On Behalf Of 
> >Nickolai Zeldovich
> >Sent: Thursday, April 29, 2004 3:27 PM
> >To: cpufreq@www.linux.org.uk
> >Subject: governor implementations
> >
> >Has there been any effort on implementing governors other than the 3
> >standard ones included in the kernel these days (powersave, performance
> >and userspace), or adding hooks to the kernel scheduler to 
> >interact with
> >the userspace governor (that is, the userspace process, and 
> >not the part
> >of cpufreq code)?
> >
> >The problem I see is that currently there's no way to do fine-grained
> >CPU speed adjustments to match the immediate user need.  
> >Currently there
> >are user-space daemons like cpuspeed that will poll your load 
> >average at
> >some intervals and adjust the CPU speed accordingly, but polling is not
> >the right answer -- you can't poll fast enough to provide a smooth user
> >experience without using up too much CPU for polling, I would guess.
> >For example, Fedora Core 2 (test3) comes with cpuspeed that slows down
> >my laptop from 1.6GHz to 600MHz.  That's great, but when I click on a
> >menu in a Gnome application, it takes a long time to come up.  Even
> >polling at 100ms, cpuspeed can't respond fast enough to this 
> >user action
> >to speed up the CPU and make the menu come up faster.
> >
> >On the other hand, implementing an in-kernel governor, or 
> >exporting user
> >callbacks like "the last tick was completely CPU bound, do something!",
> >would allow fine-grained adjustment that would increase the 
> >CPU speed as
> >soon as the user started doing something, and would similarly 
> >be able to
> >quickly decrease it back down to save power.
> >
> >So in summary, it seems to me that much better power savings and user
> >performance can be achieved by integrating cpuspeed much 
> >closer with the
> >scheduler -- I'd imagine people have thought about this already, so I'm
> >looking for references to such work out there..

-- 
David Tam <tamda@eecg.toronto.edu>
Graduate Student, ECE Dept, University of Toronto
http://www.eecg.toronto.edu/~tamda

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: governor implementations
  2004-04-30  0:37 governor implementations Pallipadi, Venkatesh
@ 2004-04-30 13:27 ` Dave Jones
  0 siblings, 0 replies; 5+ messages in thread
From: Dave Jones @ 2004-04-30 13:27 UTC (permalink / raw)
  To: Pallipadi, Venkatesh; +Cc: cpufreq, Nickolai Zeldovich

On Thu, Apr 29, 2004 at 05:37:52PM -0700, Pallipadi, Venkatesh wrote:

 > Attached is a simple in-kernel CPU frequency governor. This has some
 > minor modification to the one that I had sent on this list, couple of
 > months back.

I have one major concern about this patch.
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,298,448.WKU.&OS=PN/6,298,448&RS=PN/6,298,448

What do Intel's legal dept have to say about this?

		Dave

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: governor implementations
  2004-04-30  1:46 ` David Tam
@ 2004-05-01 18:23   ` Bruno Ducrot
  2004-05-03 14:15     ` David Tam
  0 siblings, 1 reply; 5+ messages in thread
From: Bruno Ducrot @ 2004-05-01 18:23 UTC (permalink / raw)
  To: David Tam; +Cc: wtsang, cpufreq, Catalin Drula

On Thu, Apr 29, 2004 at 09:46:40PM -0400, David Tam wrote:
> Hi.
> 
> We did some work along these lines for a grad course project in Dec 2003.
> It was done using a development version of Linux kernel 2.6.
> Unfortunately, we haven't had time to keep it up to date.
> Hopefully, it only requires minor updates.
> 
> Here is a link to the web page.  You can check out our presentation slides,
> final report, and other docs.
> http://www.eecg.toronto.edu/~tamda/csc2228/

BTW, do you want to update them (even though you think you don't have
time for) in your sparse time?
NB: floating arithmetics shall be avoided in kernel land.  It's
probably the main issue in your(s) governor(s).

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: governor implementations
  2004-05-01 18:23   ` Bruno Ducrot
@ 2004-05-03 14:15     ` David Tam
  0 siblings, 0 replies; 5+ messages in thread
From: David Tam @ 2004-05-03 14:15 UTC (permalink / raw)
  To: Bruno Ducrot; +Cc: wtsang, cpufreq, Catalin Drula

Hi.
Yes, I guess we should spent a few hours to update them and "massage"
them into a standard Linux kernel patch & loadable kernel module package.
Yes, we've been told in the past that floating point arithmetic is bad in
the kernel.  Thanks for the reminder.

On Sat, 1 May 2004, Bruno Ducrot wrote:
> On Thu, Apr 29, 2004 at 09:46:40PM -0400, David Tam wrote:
> > We did some work along these lines for a grad course project in Dec 2003.
> > It was done using a development version of Linux kernel 2.6.
> > Unfortunately, we haven't had time to keep it up to date.
> > Hopefully, it only requires minor updates.
> > 
> > Here is a link to the web page.  You can check out our presentation slides,
> > final report, and other docs.
> > http://www.eecg.toronto.edu/~tamda/csc2228/
> 
> BTW, do you want to update them (even though you think you don't have
> time for) in your sparse time?
> NB: floating arithmetics shall be avoided in kernel land.  It's
> probably the main issue in your(s) governor(s).

-- 
David Tam <tamda@eecg.toronto.edu>
Graduate Student, ECE Dept, University of Toronto
http://www.eecg.toronto.edu/~tamda

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-05-03 14:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-04-30  0:37 governor implementations Pallipadi, Venkatesh
2004-04-30 13:27 ` Dave Jones
     [not found] <E1BJM2v-0001tP-Nf@www.linux.org.uk>
2004-04-30  1:46 ` David Tam
2004-05-01 18:23   ` Bruno Ducrot
2004-05-03 14:15     ` David Tam

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.