[patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

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

This is a code reordered version of the dynamic ticks patch from Tony Lindgen 
and Tuukka Tikkanen - sorry about spamming your mail boxes with this, but 
thanks for the code. There is significant renewed interest by the lkml 
audience for such a feature which is why I'm butchering your code (sorry 
again if you don't like me doing this). The only real difference between your 
code and this patch is moving the #ifdef'd code out of code paths and putting 
it into dyn-tick specific files. 

This has slightly more build fixes than the last one I posted and boots and 
runs fine on my laptop. So far at absolute idle it appears this pentiumM 1.7 
is claiming to have _25%_ more battery life. I'll need to investigate further 
to see the real power savings. 

My desktop pentium4 did not like the patch erroring with "bad gzip magic 
number" on boot for reasons that aren't obvious to me. This could be related 
to trying gcc 4.0.1 on that box whereas the laptop is on gcc 3.4.4 and is 
working fine.

Cheers,
Con

[-- Attachment #2: 2.6.13-rc4-dtck-2.patch --]
[-- Type: text/x-diff, Size: 27009 bytes --]

Index: linux-2.6.13-rc4-ck1/arch/i386/Kconfig
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/Kconfig	2005-08-02 13:40:01.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/Kconfig	2005-08-02 13:40:51.000000000 +1000
@@ -457,6 +457,38 @@ config HPET_EMULATE_RTC
 	bool "Provide RTC interrupt"
 	depends on HPET_TIMER && RTC=y
 
+config NO_IDLE_HZ
+	bool "Dynamic Tick Timer - Skip timer ticks during idle"
+	help
+	  This option enables support for skipping timer ticks when the
+	  processor is idle. During system load, timer is continuous.
+	  This option saves power, as it allows the system to stay in
+	  idle mode longer. Currently supported timers are ACPI PM
+	  timer, local APIC timer, and TSC timer. HPET timer is currently
+	  not supported.
+
+	  Note that you need to enable dynamic tick timer either by
+	  passing dyntick=enable command line option, or via sysfs:
+
+	  # echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
+
+config DYN_TICK_USE_APIC
+	bool "Use APIC timer instead of PIT timer"
+	depends on NO_IDLE_HZ
+	help
+	  This option enables using APIC timer interrupt if your hardware
+	  supports it. APIC timer allows longer sleep periods compared
+	  to PIT timer.
+
+	  Note that on most recent hardware disabling PIT timer also
+	  disables APIC timer interrupts, and system won't run properly.
+	  Symptoms include slow system boot, and time running slow.
+
+	  If unsure, don't enable this option.
+
+	  Note that to you still need to pass dyntick=enable,forceapic
+	  command line option to use APIC timer.
+
 config SMP
 	bool "Symmetric multi-processing support"
 	---help---
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/Makefile
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/Makefile	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/Makefile	2005-08-02 13:40:51.000000000 +1000
@@ -32,6 +32,7 @@ obj-$(CONFIG_MODULES)		+= module.o
 obj-y				+= sysenter.o vsyscall.o
 obj-$(CONFIG_ACPI_SRAT) 	+= srat.o
 obj-$(CONFIG_HPET_TIMER) 	+= time_hpet.o
+obj-$(CONFIG_NO_IDLE_HZ) 	+= dyn-tick.o
 obj-$(CONFIG_EFI) 		+= efi.o efi_stub.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/apic.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/apic.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/apic.c	2005-08-02 13:40:51.000000000 +1000
@@ -27,6 +27,7 @@
 #include <linux/kernel_stat.h>
 #include <linux/sysdev.h>
 #include <linux/cpu.h>
+#include <linux/dyn-tick.h>
 
 #include <asm/atomic.h>
 #include <asm/smp.h>
@@ -931,6 +932,8 @@ void (*wait_timer_tick)(void) __devinitd
 
 #define APIC_DIVISOR 16
 
+u32 apic_timer_val;
+
 static void __setup_APIC_LVTT(unsigned int clocks)
 {
 	unsigned int lvtt_value, tmp_value, ver;
@@ -949,7 +952,12 @@ static void __setup_APIC_LVTT(unsigned i
 				& ~(APIC_TDR_DIV_1 | APIC_TDR_DIV_TMBASE))
 				| APIC_TDR_DIV_16);
 
-	apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
+	apic_timer_val = clocks/APIC_DIVISOR;
+
+	if (apic_timer_val)
+		set_dyn_tick_max_skip(apic_timer_val);
+
+	apic_write_around(APIC_TMICT, apic_timer_val);
 }
 
 static void __devinit setup_APIC_timer(unsigned int clocks)
@@ -1062,6 +1070,8 @@ void __init setup_boot_APIC_clock(void)
 	 */
 	setup_APIC_timer(calibration_result);
 
+	setup_dyn_tick_use_apic(calibration_result);
+
 	local_irq_enable();
 }
 
@@ -1200,6 +1210,13 @@ fastcall void smp_apic_timer_interrupt(s
 	 * interrupt lock, which is the WrongThing (tm) to do.
 	 */
 	irq_enter();
+
+	/*
+	 * Check if we need to wake up PIT interrupt handler.
+	 * Otherwise just wake up local APIC timer.
+	 */
+	wakeup_pit_or_apic(cpu, regs);
+
 	smp_local_timer_interrupt(regs);
 	irq_exit();
 }
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/dyn-tick.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/dyn-tick.c	2005-08-02 13:54:45.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/dyn-tick.c	2005-08-02 13:40:51.000000000 +1000
@@ -0,0 +1,164 @@
+/*
+ * linux/arch/i386/kernel/dyn-tick.c
+ *
+ * Copyright (C) 2004 Nokia Corporation
+ * Written by Tony Lindgen <tony@atomide.com> and
+ * Tuukka Tikkanen <tuukka.tikkanen@elektrobit.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/version.h>
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/dyn-tick.h>
+#include <asm/apic.h>
+
+#ifdef CONFIG_X86_LOCAL_APIC
+void reprogram_apic_timer(unsigned int count)
+{
+	unsigned long flags;
+
+	count *= apic_timer_val;
+	local_irq_save(flags);
+	apic_write_around(APIC_TMICT, count);
+	local_irq_restore(flags);
+}
+#else
+void reprogram_apic_timer(unsigned int count)
+{
+}
+
+#endif
+
+void arch_reprogram_timer(void)
+{
+	if (cpu_has_local_apic()) {
+		disable_pit_timer();
+		if (dyn_tick->state & DYN_TICK_TIMER_INT)
+			reprogram_apic_timer(dyn_tick->skip);
+	} else {
+		if (dyn_tick->state & DYN_TICK_TIMER_INT)
+			reprogram_pit_timer(dyn_tick->skip);
+		else
+			disable_pit_timer();
+	}
+}
+
+static struct dyn_tick_timer arch_dyn_tick_timer = {
+	.arch_reprogram_timer	= &arch_reprogram_timer,
+};
+
+int __init dyn_tick_init(void)
+{
+	arch_dyn_tick_timer.arch_init = dyn_tick_arch_init;
+	dyn_tick_register(&arch_dyn_tick_timer);
+
+	return 0;
+}
+arch_initcall(dyn_tick_init);
+
+static unsigned long long last_tick;
+
+/*
+ * This interrupt handler updates the time based on number of jiffies skipped
+ * It would be somewhat more optimized to have a customa handler in each timer
+ * using hardware ticks instead of nanoseconds. Note that CONFIG_NO_IDLE_HZ
+ * currently disables timer fallback on skipped jiffies.
+ */
+irqreturn_t dyn_tick_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	unsigned long flags;
+	volatile unsigned long long now;
+	unsigned int skipped = 0;
+
+	write_seqlock_irqsave(&xtime_lock, flags);
+	now = cur_timer->monotonic_clock();
+	while (now - last_tick >= NS_TICK_LEN) {
+		last_tick += NS_TICK_LEN;
+		cur_timer->mark_offset();
+		do_timer_interrupt(irq, NULL, regs);
+		skipped++;
+	}
+	if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+		dyn_tick->skip = 1;
+		if (cpu_has_local_apic())
+			reprogram_apic_timer(dyn_tick->skip);
+		reprogram_pit_timer(dyn_tick->skip);
+		dyn_tick->state |= DYN_TICK_ENABLED;
+		dyn_tick->state &= ~DYN_TICK_SKIPPING;
+	}
+	write_sequnlock_irqrestore(&xtime_lock, flags);
+
+	return IRQ_HANDLED;
+}
+
+int __init dyn_tick_arch_init(void)
+{
+	unsigned long flags;
+
+	write_seqlock_irqsave(&xtime_lock, flags);
+	last_tick = cur_timer->monotonic_clock();
+	dyn_tick->skip = 1;
+	if (!(dyn_tick->state & DYN_TICK_USE_APIC) || !cpu_has_local_apic())
+		dyn_tick->max_skip = 0xffff/LATCH;	/* PIT timer length */
+	printk(KERN_INFO "dyn-tick: Maximum ticks to skip limited to %i\n",
+	       dyn_tick->max_skip);
+	write_sequnlock_irqrestore(&xtime_lock, flags);
+
+	dyn_tick->interrupt = dyn_tick_timer_interrupt;
+	replace_timer_interrupt(dyn_tick->interrupt);
+
+	return 0;
+}
+
+/* Functions that need blank prototypes for !CONFIG_NO_IDLE_HZ below here */
+inline void set_dyn_tick_max_skip(u32 apic_timer_val)
+{
+	dyn_tick->max_skip = 0xffffff / apic_timer_val;
+}
+
+inline void setup_dyn_tick_use_apic(unsigned int calibration_result)
+{
+	if (calibration_result)
+		dyn_tick->state |= DYN_TICK_USE_APIC;
+	else
+		printk(KERN_INFO "dyn-tick: Cannot use local APIC\n");
+}
+
+void wakeup_pit_or_apic(int cpu, struct pt_regs *regs)
+{
+	unsigned long seq; 
+
+	do {
+		seq = read_seqbegin(&xtime_lock);
+		if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING)) {
+			if (dyn_tick->skip_cpu == cpu && dyn_tick->skip > DYN_TICK_MIN_SKIP)
+				dyn_tick->interrupt(99, NULL, regs);
+			else
+				reprogram_apic_timer(1);
+		}
+	} while (read_seqretry(&xtime_lock, seq));
+}
+
+void dyn_tick_interrupt(int irq, struct pt_regs *regs)
+{
+	if (dyn_tick->state & (DYN_TICK_ENABLED | DYN_TICK_SKIPPING) && irq != 0)
+		dyn_tick->interrupt(irq, NULL, regs);
+}
+
+void dyn_tick_time_init(struct timer_opts *cur_timer)
+{
+	if (strncmp(cur_timer->name, "tsc", 3) == 0 ||
+	    strncmp(cur_timer->name, "pmtmr", 3) == 0) {
+		dyn_tick->state |= DYN_TICK_SUITABLE;
+		printk(KERN_INFO "dyn-tick: Found suitable timer: %s\n",
+		       cur_timer->name);
+	} else
+		printk(KERN_ERR "dyn-tick: Cannot use timer %s\n",
+		       cur_timer->name);
+}
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/irq.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/irq.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/irq.c	2005-08-02 13:40:51.000000000 +1000
@@ -18,6 +18,7 @@
 #include <linux/notifier.h>
 #include <linux/cpu.h>
 #include <linux/delay.h>
+#include <linux/dyn-tick.h>
 
 DEFINE_PER_CPU(irq_cpustat_t, irq_stat) ____cacheline_maxaligned_in_smp;
 EXPORT_PER_CPU_SYMBOL(irq_stat);
@@ -76,6 +77,8 @@ fastcall unsigned int do_IRQ(struct pt_r
 	}
 #endif
 
+	dyn_tick_interrupt(irq, regs);
+
 #ifdef CONFIG_4KSTACKS
 
 	curctx = (union irq_ctx *) current_thread_info();
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/process.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/process.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/process.c	2005-08-02 13:40:51.000000000 +1000
@@ -39,6 +39,7 @@
 #include <linux/ptrace.h>
 #include <linux/random.h>
 #include <linux/kprobes.h>
+#include <linux/dyn-tick.h>
 
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
@@ -200,6 +201,8 @@ void cpu_idle(void)
 			if (cpu_is_offline(cpu))
 				play_dead();
 
+			dyn_tick_reprogram_timer();
+
 			__get_cpu_var(irq_stat).idle_timestamp = jiffies;
 			idle();
 		}
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/time.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/time.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/time.c	2005-08-02 13:46:18.000000000 +1000
@@ -46,6 +46,7 @@
 #include <linux/bcd.h>
 #include <linux/efi.h>
 #include <linux/mca.h>
+#include <linux/dyn-tick.h>
 
 #include <asm/io.h>
 #include <asm/smp.h>
@@ -252,7 +253,7 @@ EXPORT_SYMBOL(profile_pc);
  * timer_interrupt() needs to keep up the real-time clock,
  * as well as call the "do_timer()" routine every clocktick
  */
-static inline void do_timer_interrupt(int irq, void *dev_id,
+inline void do_timer_interrupt(int irq, void *dev_id,
 					struct pt_regs *regs)
 {
 #ifdef CONFIG_X86_IO_APIC
@@ -423,7 +424,7 @@ static struct sysdev_class timer_sysclas
 
 
 /* XXX this driverfs stuff should probably go elsewhere later -john */
-static struct sys_device device_timer = {
+struct sys_device device_timer = {
 	.id	= 0,
 	.cls	= &timer_sysclass,
 };
@@ -479,5 +480,7 @@ void __init time_init(void)
 	cur_timer = select_timer();
 	printk(KERN_INFO "Using %s for high-res timesource\n",cur_timer->name);
 
+	dyn_tick_time_init(cur_timer);
+
 	time_init_hook();
 }
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/timers/timer_pit.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/timers/timer_pit.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/timers/timer_pit.c	2005-08-02 13:40:51.000000000 +1000
@@ -148,6 +148,43 @@ static unsigned long get_offset_pit(void
 	return count;
 }
 
+/*
+ * REVISIT: Looks like on P3 APIC timer keeps running if PIT mode
+ *	    is changed. On P4, changing PIT mode seems to kill
+ *	    APIC timer interrupts. Same thing with disabling PIT
+ *	    interrupt.
+ */
+void disable_pit_timer(void)
+{
+	extern spinlock_t i8253_lock;
+	unsigned long flags;
+	spin_lock_irqsave(&i8253_lock, flags);
+	outb_p(0x32, PIT_MODE);		/* binary, mode 1, LSB/MSB, ch 0 */
+	spin_unlock_irqrestore(&i8253_lock, flags);
+}
+
+/*
+ * Reprograms the next timer interrupt
+ * PIT timer reprogramming code taken from APM code.
+ * Note that PIT timer is a 16-bit timer, which allows max
+ * skip of only few seconds.
+ */
+void reprogram_pit_timer(int jiffies_to_skip)
+{
+	int skip;
+	extern spinlock_t i8253_lock;
+	unsigned long flags;
+
+	skip = jiffies_to_skip * LATCH;
+	if (skip > 0xffff)
+		skip = 0xffff;
+
+	spin_lock_irqsave(&i8253_lock, flags);
+	outb_p(0x34, PIT_MODE);		/* binary, mode 2, LSB/MSB, ch 0 */
+	outb_p(skip & 0xff, PIT_CH0);	/* LSB */
+	outb(skip >> 8, PIT_CH0);	/* MSB */
+	spin_unlock_irqrestore(&i8253_lock, flags);
+}
 
 /* tsc timer_opts struct */
 struct timer_opts timer_pit = {
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/timers/timer_pm.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/timers/timer_pm.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/timers/timer_pm.c	2005-08-02 13:40:51.000000000 +1000
@@ -15,6 +15,7 @@
 #include <linux/module.h>
 #include <linux/device.h>
 #include <linux/init.h>
+#include <linux/dyn-tick.h>
 #include <asm/types.h>
 #include <asm/timer.h>
 #include <asm/smp.h>
@@ -168,6 +169,9 @@ static void mark_offset_pmtmr(void)
 	monotonic_base += delta * NSEC_PER_USEC;
 	write_sequnlock(&monotonic_lock);
 
+	if (dyn_tick_enabled())
+		return;
+
 	/* convert to ticks */
 	delta += offset_delay;
 	lost = delta / (USEC_PER_SEC / HZ);
Index: linux-2.6.13-rc4-ck1/arch/i386/kernel/timers/timer_tsc.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/kernel/timers/timer_tsc.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/kernel/timers/timer_tsc.c	2005-08-02 13:40:51.000000000 +1000
@@ -14,6 +14,7 @@
 #include <linux/cpufreq.h>
 #include <linux/string.h>
 #include <linux/jiffies.h>
+#include <linux/dyn-tick.h>
 
 #include <asm/timer.h>
 #include <asm/io.h>
@@ -367,6 +368,9 @@ static void mark_offset_tsc(void)
 
 	rdtsc(last_tsc_low, last_tsc_high);
 
+	if (dyn_tick_enabled())
+		goto monotonic_base;
+
 	spin_lock(&i8253_lock);
 	outb_p(0x00, PIT_MODE);     /* latch the count ASAP */
 
@@ -434,11 +438,17 @@ static void mark_offset_tsc(void)
 			cpufreq_delayed_get();
 	} else
 		lost_count = 0;
+
+ monotonic_base:
+
 	/* update the monotonic base value */
 	this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low;
 	monotonic_base += cycles_2_ns(this_offset - last_offset);
 	write_sequnlock(&monotonic_lock);
 
+	if (dyn_tick_enabled())
+		return;
+
 	/* calculate delay_at_last_interrupt */
 	count = ((LATCH-1) - count) * TICK_SIZE;
 	delay_at_last_interrupt = (count + LATCH/2) / LATCH;
Index: linux-2.6.13-rc4-ck1/arch/i386/mach-default/setup.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/arch/i386/mach-default/setup.c	2005-08-02 13:38:53.000000000 +1000
+++ linux-2.6.13-rc4-ck1/arch/i386/mach-default/setup.c	2005-08-02 13:40:51.000000000 +1000
@@ -93,6 +93,22 @@ void __init time_init_hook(void)
 	setup_irq(0, &irq0);
 }
 
+/**
+ * replace_timer_interrupt - allow replacing timer interrupt handler
+ *
+ * Description:
+ *	Can be used to replace timer interrupt handler with a more optimized
+ *	handler. Used for enabling and disabling of CONFIG_NO_IDLE_HZ.
+ */
+void replace_timer_interrupt(void * new_handler)
+{
+	unsigned long flags;
+
+	write_seqlock_irqsave(&xtime_lock, flags);
+	irq0.handler = new_handler;
+	write_sequnlock_irqrestore(&xtime_lock, flags);
+}
+
 #ifdef CONFIG_MCA
 /**
  * mca_nmi_hook - hook into MCA specific NMI chain
Index: linux-2.6.13-rc4-ck1/include/asm-i386/dyn-tick.h
===================================================================
--- linux-2.6.13-rc4-ck1.orig/include/asm-i386/dyn-tick.h	2005-08-02 13:54:45.000000000 +1000
+++ linux-2.6.13-rc4-ck1/include/asm-i386/dyn-tick.h	2005-08-02 13:43:46.000000000 +1000
@@ -0,0 +1,66 @@
+/*
+ * linux/include/asm-i386/dyn-tick.h
+ *
+ * Copyright (C) 2004 Nokia Corporation
+ * Written by Tony Lindgen <tony@atomide.com> and
+ * Tuukka Tikkanen <tuukka.tikkanen@elektrobit.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.
+ */
+
+#ifndef _ASM_I386_DYN_TICK_H_
+#define _ASM_I386_DYN_TICK_H_
+
+#ifdef CONFIG_NO_IDLE_HZ
+extern int dyn_tick_arch_init(void);
+extern void disable_pit_timer(void);
+extern void reprogram_pit_timer(int jiffies_to_skip);
+extern void reprogram_apic_timer(unsigned int count);
+extern void replace_timer_interrupt(void * new_handler);
+
+extern void set_dyn_tick_max_skip(u32 apic_timer_val);
+extern void setup_dyn_tick_use_apic(unsigned int calibration_result);
+extern void wakeup_pit_or_apic(int cpu, struct pt_regs *regs);
+extern void dyn_tick_interrupt(int irq, struct pt_regs *regs);
+extern void dyn_tick_time_init(struct timer_opts *cur_timer);
+extern void do_timer_interrupt(int irq, void *dev_id,
+					struct pt_regs *regs);
+
+extern irqreturn_t dyn_tick_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs);
+extern int __init dyn_tick_arch_init(void);
+extern u32 apic_timer_val;
+
+#if defined(CONFIG_DYN_TICK_USE_APIC) && (defined(CONFIG_SMP) || defined(CONFIG_X86_UP_APIC))
+#define cpu_has_local_apic()	(dyn_tick->state & DYN_TICK_USE_APIC)
+#else
+#define cpu_has_local_apic()	0
+#endif
+
+#else /* CONFIG_NO_IDLE_HZ */
+static inline void set_dyn_tick_max_skip(u32 apic_timer_val)
+{
+}
+
+static inline void reprogram_apic_timer(unsigned int count)
+{
+}
+
+static inline void setup_dyn_tick_use_apic(unsigned int calibration_result)
+{
+}
+
+static inline void wakeup_pit_or_apic(int cpu, struct pt_regs *regs)
+{
+}
+
+static inline void dyn_tick_interrupt(int irq, struct pt_regs *regs)
+{
+}
+
+static inline void dyn_tick_time_init(struct timer_opts *cur_timer)
+{
+}
+#endif /* CONFIG_NO_IDLE_HZ */
+#endif /* _ASM_I386_DYN_TICK_H_ */
Index: linux-2.6.13-rc4-ck1/include/linux/dyn-tick.h
===================================================================
--- linux-2.6.13-rc4-ck1.orig/include/linux/dyn-tick.h	2005-08-02 13:54:45.000000000 +1000
+++ linux-2.6.13-rc4-ck1/include/linux/dyn-tick.h	2005-08-02 13:40:51.000000000 +1000
@@ -0,0 +1,66 @@
+/*
+ * linux/include/linux/dyn-tick.h
+ *
+ * Copyright (C) 2004 Nokia Corporation
+ * Written by Tony Lindgen <tony@atomide.com> and
+ * Tuukka Tikkanen <tuukka.tikkanen@elektrobit.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.
+ */
+
+#ifndef _DYN_TICK_TIMER_H
+#define _DYN_TICK_TIMER_H
+
+#include <linux/interrupt.h>
+#include <asm/timer.h>
+
+#define DYN_TICK_TIMER_INT	(1 << 4)
+#define DYN_TICK_USE_APIC	(1 << 3)
+#define DYN_TICK_SKIPPING	(1 << 2)
+#define DYN_TICK_ENABLED	(1 << 1)
+#define DYN_TICK_SUITABLE	(1 << 0)
+
+struct dyn_tick_state {
+	unsigned int state;		/* Current state */
+	int skip_cpu;			/* Skip handling processor */
+	unsigned long skip;		/* Ticks to skip */
+	unsigned int max_skip;		/* Max number of ticks to skip */
+	unsigned long irq_skip_mask;	/* Do not update time from these irqs */
+	irqreturn_t (*interrupt)(int, void *, struct pt_regs *);
+};
+
+struct dyn_tick_timer {
+	int (*arch_init) (void);
+	void (*arch_enable) (void);
+	void (*arch_disable) (void);
+	void (*arch_reprogram_timer) (void);
+};
+
+extern struct dyn_tick_state * dyn_tick;
+extern void dyn_tick_register(struct dyn_tick_timer * new_timer);
+
+#define NS_TICK_LEN		((1 * 1000000000)/HZ)
+#define DYN_TICK_MIN_SKIP	2
+
+
+#ifdef CONFIG_NO_IDLE_HZ
+
+extern unsigned long dyn_tick_reprogram_timer(void);
+
+#define dyn_tick_enabled()		(dyn_tick->state & DYN_TICK_ENABLED)
+
+#else
+
+#define arch_has_safe_halt()		0
+#define dyn_tick_reprogram_timer()	do {} while (0)
+#define dyn_tick_enabled()		0
+
+#endif	/* CONFIG_NO_IDLE_HZ */
+
+
+/* Pick up arch specific header */
+#include <asm/dyn-tick.h>
+
+#endif	/* _DYN_TICK_TIMER_H */
Index: linux-2.6.13-rc4-ck1/kernel/Makefile
===================================================================
--- linux-2.6.13-rc4-ck1.orig/kernel/Makefile	2005-08-02 13:38:57.000000000 +1000
+++ linux-2.6.13-rc4-ck1/kernel/Makefile	2005-08-02 13:40:51.000000000 +1000
@@ -30,6 +30,7 @@ obj-$(CONFIG_SYSFS) += ksysfs.o
 obj-$(CONFIG_GENERIC_HARDIRQS) += irq/
 obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
 obj-$(CONFIG_SECCOMP) += seccomp.o
+obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o
 
 ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
Index: linux-2.6.13-rc4-ck1/kernel/dyn-tick.c
===================================================================
--- linux-2.6.13-rc4-ck1.orig/kernel/dyn-tick.c	2005-08-02 13:54:45.000000000 +1000
+++ linux-2.6.13-rc4-ck1/kernel/dyn-tick.c	2005-08-02 14:26:42.000000000 +1000
@@ -0,0 +1,212 @@
+/*
+ * linux/kernel/dyn-tick.c
+ *
+ * Beginnings of generic dynamic tick timer support
+ *
+ * Copyright (C) 2004 Nokia Corporation
+ * Written by Tony Lindgen <tony@atomide.com> and
+ * Tuukka Tikkanen <tuukka.tikkanen@elektrobit.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/version.h>
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/sysdev.h>
+#include <linux/interrupt.h>
+#include <linux/cpumask.h>
+#include <linux/pm.h>
+#include <linux/dyn-tick.h>
+#include <asm/io.h>
+
+#include "io_ports.h"
+
+#define DYN_TICK_VERSION	"050610-1"
+
+struct dyn_tick_state dyn_tick_state;
+struct dyn_tick_state * dyn_tick = &dyn_tick_state;
+struct dyn_tick_timer * dyn_tick_cfg;
+static cpumask_t dyn_cpu_map;
+
+/*
+ * Arch independed code needed to reprogram next timer interrupt.
+ * Gets called from cpu_idle() before entering idle loop. Note that
+ * we want to have all processors idle before reprogramming the
+ * next timer interrupt.
+ */
+unsigned long dyn_tick_reprogram_timer(void)
+{
+	int cpu;
+	unsigned long flags;
+	cpumask_t idle_cpus;
+	unsigned long next;
+
+	if (!(dyn_tick->state & DYN_TICK_ENABLED))
+		return 0;
+
+	/* Check if we are already skipping ticks and can idle other cpus */
+	if (dyn_tick->state & DYN_TICK_SKIPPING) {
+		if (cpu_has_local_apic())
+			reprogram_apic_timer(dyn_tick->skip);
+		return 0;
+	}
+
+	/* Check if we can start skipping ticks */
+	write_seqlock_irqsave(&xtime_lock, flags);
+	cpu = smp_processor_id();
+	cpu_set(cpu, dyn_cpu_map);
+	cpus_and(idle_cpus, dyn_cpu_map, cpu_online_map);
+	if (cpus_equal(idle_cpus, cpu_online_map)) {
+		next = next_timer_interrupt();
+		if (jiffies > next)
+			dyn_tick->skip = 1;
+		else
+			dyn_tick->skip = next_timer_interrupt() - jiffies;
+		if (dyn_tick->skip > DYN_TICK_MIN_SKIP) {
+			if (dyn_tick->skip > dyn_tick->max_skip)
+				dyn_tick->skip = dyn_tick->max_skip;
+
+			dyn_tick_cfg->arch_reprogram_timer();
+
+			dyn_tick->skip_cpu = cpu;
+			dyn_tick->state |= DYN_TICK_SKIPPING;
+		}
+		cpus_clear(dyn_cpu_map);
+	}
+	write_sequnlock_irqrestore(&xtime_lock, flags);
+
+	return dyn_tick->skip;
+}
+
+void __init dyn_tick_register(struct dyn_tick_timer * arch_timer)
+{
+	dyn_tick_cfg = arch_timer;
+	printk(KERN_INFO "dyn-tick: Registering dynamic tick timer v%s\n",
+	       DYN_TICK_VERSION);
+}
+
+/*
+ * ---------------------------------------------------------------------------
+ * Command line options
+ * ---------------------------------------------------------------------------
+ */
+static int __initdata dyntick_autoenable = 0;
+static int __initdata dyntick_useapic = 0;
+
+/*
+ * dyntick=[enable|disable],[forceapic]
+ */ 
+static int __init dyntick_setup(char *options)
+{
+	if (!options)
+		return 0;
+
+	if (!strncmp(options, "enable", 6)) 
+		dyntick_autoenable = 1;
+
+	if (strstr(options, "forceapic"))
+		dyntick_useapic = 1;
+
+	return 0;
+}
+
+__setup("dyntick=", dyntick_setup);
+
+/*
+ * ---------------------------------------------------------------------------
+ * Sysfs interface
+ * ---------------------------------------------------------------------------
+ */
+
+extern struct sys_device device_timer;
+
+#define DYN_TICK_IS_SET(x)	((dyn_tick->state & (x)) == (x))
+
+static ssize_t show_dyn_tick_state(struct sys_device *dev, char *buf)
+{
+	return sprintf(buf,
+		       "suitable:\t%i\n"
+		       "enabled:\t%i\n"
+		       "using APIC:\t%i\n",
+		       DYN_TICK_IS_SET(DYN_TICK_SUITABLE),
+		       DYN_TICK_IS_SET(DYN_TICK_ENABLED),
+		       DYN_TICK_IS_SET(DYN_TICK_USE_APIC));
+}
+
+static ssize_t set_dyn_tick_state(struct sys_device *dev, const char * buf,
+				size_t count)
+{
+	unsigned long flags;
+	unsigned int enable = simple_strtoul(buf, NULL, 2);
+
+	write_seqlock_irqsave(&xtime_lock, flags);
+	if (enable) {
+		if (dyn_tick_cfg->arch_enable)
+			dyn_tick_cfg->arch_enable();
+		dyn_tick->state |= DYN_TICK_ENABLED;
+	} else {
+		if (dyn_tick_cfg->arch_disable)
+			dyn_tick_cfg->arch_disable();
+		dyn_tick->state &= ~DYN_TICK_ENABLED;
+	}
+	write_sequnlock_irqrestore(&xtime_lock, flags);
+
+	return count;
+}
+
+static SYSDEV_ATTR(dyn_tick_state, 0644, show_dyn_tick_state,
+		   set_dyn_tick_state);
+
+/*
+ * ---------------------------------------------------------------------------
+ * Init functions
+ * ---------------------------------------------------------------------------
+ */
+
+static int __init dyn_tick_early_init(void)
+{
+	dyn_tick->state |= DYN_TICK_TIMER_INT;
+	return 0;
+}
+
+subsys_initcall(dyn_tick_early_init);
+
+/*
+ * We need to initialize dynamic tick after calibrate delay
+ */
+static int __init dyn_tick_late_init(void)
+{
+	int ret = 0;
+
+	if (dyn_tick_cfg == NULL || dyn_tick_cfg->arch_init == NULL ||
+	    !(dyn_tick->state & DYN_TICK_SUITABLE)) {
+		printk(KERN_ERR "dyn-tick: No suitable timer found\n");
+		return -ENODEV;
+	}
+
+	if (!dyntick_useapic)
+		dyn_tick->state &= ~DYN_TICK_USE_APIC;
+
+	ret = dyn_tick_cfg->arch_init();
+	if (ret != 0) {
+		printk(KERN_ERR "dyn-tick: Init failed\n");
+		return -ENODEV;
+	}
+
+	ret = sysdev_create_file(&device_timer, &attr_dyn_tick_state);
+
+	if (ret == 0 && dyntick_autoenable) {
+		dyn_tick->state |= DYN_TICK_ENABLED;
+		printk(KERN_INFO "dyn-tick: Timer using dynamic tick\n");
+	} else
+		printk(KERN_INFO "dyn-tick: Timer not enabled during boot\n");
+
+	return ret;
+}
+
+late_initcall(dyn_tick_late_init);

Re: [ck] [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Michael Marineau]

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

Con Kolivas wrote:
> My desktop pentium4 did not like the patch erroring with "bad gzip magic 
> number" on boot for reasons that aren't obvious to me. This could be related 
> to trying gcc 4.0.1 on that box whereas the laptop is on gcc 3.4.4 and is 
> working fine.
> 

Just writing to report that on my laptop with a pentium 4 m that it
boots just fine. No idea what the change in power use is at the moment.
Compiled using gcc 3.3.5.

-- 
Michael Marineau
marineam@engr.orst.edu
Oregon State University

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Tue, 2 Aug 2005 02:43 pm, Con Kolivas wrote:
> This has slightly more build fixes than the last one I posted and boots and
> runs fine on my laptop. So far at absolute idle it appears this pentiumM
> 1.7 is claiming to have _25%_ more battery life. I'll need to investigate
> further to see the real power savings.

As a crude data point of idle system running a full kde desktop environment on 
powersave with minimal backlight and just chatting on IRC I find it's just 
under 10% battery life difference. I have confirmed in the past the accuracy 
of the remaining capacity exported by the battery and the time to complete 
discharge. This saving is similar in magnitude to the 1000->100Hz savings of 
7% mentioned on other threads. While nothing like the 25% initially suggested 
it is still significant. Anyone with a more accurate means of testing this 
interested?

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Lee Revell]

On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> As a crude data point of idle system running a full kde desktop
> environment on 
> powersave with minimal backlight and just chatting on IRC I find it's
> just 
> under 10% battery life difference.

Have you tried the same test but without artsd, or with it configured to
release the sound device after some reasonable time, like 1-2s?  

Lee

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > As a crude data point of idle system running a full kde desktop
> > environment on
> > powersave with minimal backlight and just chatting on IRC I find it's
> > just
> > under 10% battery life difference.
>
> Have you tried the same test but without artsd, or with it configured to
> release the sound device after some reasonable time, like 1-2s?

I have it on release after 1 second already.

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Lee Revell]

On Tue, 2005-08-02 at 15:56 +1000, Con Kolivas wrote:
> On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > > As a crude data point of idle system running a full kde desktop
> > > environment on
> > > powersave with minimal backlight and just chatting on IRC I find it's
> > > just
> > > under 10% battery life difference.
> >
> > Have you tried the same test but without artsd, or with it configured to
> > release the sound device after some reasonable time, like 1-2s?
> 
> I have it on release after 1 second already.

Is there any difference in power use between this, and not running artsd
at all?

Lee

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Tony Lindgren]

* Lee Revell <rlrevell@joe-job.com> [050801 23:24]:
> On Tue, 2005-08-02 at 15:56 +1000, Con Kolivas wrote:
> > On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> > > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > > > As a crude data point of idle system running a full kde desktop
> > > > environment on
> > > > powersave with minimal backlight and just chatting on IRC I find it's
> > > > just
> > > > under 10% battery life difference.
> > >
> > > Have you tried the same test but without artsd, or with it configured to
> > > release the sound device after some reasonable time, like 1-2s?
> > 
> > I have it on release after 1 second already.
> 
> Is there any difference in power use between this, and not running artsd
> at all?

Please have the pmstats from http://www.muru.com/linux/dyntick running
in once console with pmstats 5, and then just kill programs to find out
which ones use lots of timers. CPU monitors etc.

You should get X running at about 25HZ, (which is the PIT limit usually)
Higher ticks means means polling somewhere which totally kills any power
savings.

There's still some places in kernel that also do polling as far as I remember:

- AT keyboard if no keyboard connected
- Netfilter code (Unverified)

But this you can verify by booting to single user mode and then running
pmstats 5, and if ticks is not below 25HZ, there's something in the kernel
polling.

Reagrds,

Tony

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Tony Lindgren]

* Con Kolivas <kernel@kolivas.org> [050801 21:41]:
> This is a code reordered version of the dynamic ticks patch from Tony Lindgen 
> and Tuukka Tikkanen - sorry about spamming your mail boxes with this, but 
> thanks for the code. There is significant renewed interest by the lkml 
> audience for such a feature which is why I'm butchering your code (sorry 
> again if you don't like me doing this). The only real difference between your 
> code and this patch is moving the #ifdef'd code out of code paths and putting 
> it into dyn-tick specific files. 

Great! We ported it from ARM to x86 so people could develop it further. Help
is really appreciated to get it into shape for integration.

> This has slightly more build fixes than the last one I posted and boots and 
> runs fine on my laptop. So far at absolute idle it appears this pentiumM 1.7 
> is claiming to have _25%_ more battery life. I'll need to investigate further 
> to see the real power savings. 

What is your HZ according to pmstats?

> My desktop pentium4 did not like the patch erroring with "bad gzip magic 
> number" on boot for reasons that aren't obvious to me. This could be related 
> to trying gcc 4.0.1 on that box whereas the laptop is on gcc 3.4.4 and is 
> working fine.

Yeah, this sounds like an issue with the decompression code.

Tony

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Tue, 2 Aug 2005 05:17 pm, Tony Lindgren wrote:
> * Lee Revell <rlrevell@joe-job.com> [050801 23:24]:
> > On Tue, 2005-08-02 at 15:56 +1000, Con Kolivas wrote:
> > > On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> > > > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > > > > As a crude data point of idle system running a full kde desktop
> > > > > environment on
> > > > > powersave with minimal backlight and just chatting on IRC I find
> > > > > it's just
> > > > > under 10% battery life difference.
> > > >
> > > > Have you tried the same test but without artsd, or with it configured
> > > > to release the sound device after some reasonable time, like 1-2s?
> > >
> > > I have it on release after 1 second already.
> >
> > Is there any difference in power use between this, and not running artsd
> > at all?
>
> Please have the pmstats from http://www.muru.com/linux/dyntick running
> in once console with pmstats 5, and then just kill programs to find out
> which ones use lots of timers. CPU monitors etc.
>
> You should get X running at about 25HZ, (which is the PIT limit usually)
> Higher ticks means means polling somewhere which totally kills any power
> savings.

Ok I seem to be bottoming out at 130Hz. I can't seem to kill off anything 
more.

>
> There's still some places in kernel that also do polling as far as I
> remember:
>
> - AT keyboard if no keyboard connected
> - Netfilter code (Unverified)
>
> But this you can verify by booting to single user mode and then running
> pmstats 5, and if ticks is not below 25HZ, there's something in the kernel
> polling.

I'm removing modules and they don't seem to do anything so I'm not sure what 
else to try.

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Tony Lindgren]

* Con Kolivas <kernel@kolivas.org> [050802 00:36]:
> On Tue, 2 Aug 2005 05:17 pm, Tony Lindgren wrote:
> > * Lee Revell <rlrevell@joe-job.com> [050801 23:24]:
> > > On Tue, 2005-08-02 at 15:56 +1000, Con Kolivas wrote:
> > > > On Tue, 2 Aug 2005 03:52 pm, Lee Revell wrote:
> > > > > On Tue, 2005-08-02 at 15:49 +1000, Con Kolivas wrote:
> > > > > > As a crude data point of idle system running a full kde desktop
> > > > > > environment on
> > > > > > powersave with minimal backlight and just chatting on IRC I find
> > > > > > it's just
> > > > > > under 10% battery life difference.
> > > > >
> > > > > Have you tried the same test but without artsd, or with it configured
> > > > > to release the sound device after some reasonable time, like 1-2s?
> > > >
> > > > I have it on release after 1 second already.
> > >
> > > Is there any difference in power use between this, and not running artsd
> > > at all?
> >
> > Please have the pmstats from http://www.muru.com/linux/dyntick running
> > in once console with pmstats 5, and then just kill programs to find out
> > which ones use lots of timers. CPU monitors etc.
> >
> > You should get X running at about 25HZ, (which is the PIT limit usually)
> > Higher ticks means means polling somewhere which totally kills any power
> > savings.
> 
> Ok I seem to be bottoming out at 130Hz. I can't seem to kill off anything 
> more.
> 
> >
> > There's still some places in kernel that also do polling as far as I
> > remember:
> >
> > - AT keyboard if no keyboard connected
> > - Netfilter code (Unverified)
> >
> > But this you can verify by booting to single user mode and then running
> > pmstats 5, and if ticks is not below 25HZ, there's something in the kernel
> > polling.
> 
> I'm removing modules and they don't seem to do anything so I'm not sure what 
> else to try.

If you have 130HZ in single user mode, it's some kernel driver.
You could printk the the next timer, then grep for that in System.map:

--- linux-2.6.orig/kernel/timer.c	2005-06-27 07:51:58.000000000 -0700
+++ linux-2.6/kernel/timer.c	2005-06-28 06:57:27.000000000 -0700
@@ -571,6 +571,7 @@
 				expires = nte->expires;
 		}
 	}
+	printk("next: %08x\n", nte->function);
 	spin_unlock(&base->t_base.lock);
 	return expires;
 }

Of course the console will be useless with this patch :)

I really need to do the timertop utility at some point...

Tony

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Tue, 2 Aug 2005 18:15, Tony Lindgren wrote:
> * Con Kolivas <kernel@kolivas.org> [050802 00:36]:
> > On Tue, 2 Aug 2005 05:17 pm, Tony Lindgren wrote:
> > > But this you can verify by booting to single user mode and then running
> > > pmstats 5, and if ticks is not below 25HZ, there's something in the
> > > kernel polling.
> >
> > I'm removing modules and they don't seem to do anything so I'm not sure
> > what else to try.
>
> If you have 130HZ in single user mode, it's some kernel driver.
> You could printk the the next timer, then grep for that in System.map:

I kept pulling modules and eventually got to 27Hz so something was definitely 
happening.

I need to ask you why you think limiting the maximum Hz is a bad idea? On a 
laptop, say we have set the powersave governor, we have already told the 
kernel we are interested in maximising power saving at the expense of 
performance. Would it not be appropriate for this to be linked in a way that 
sets maximum Hz to some value that maximises power save (whatever that value 
is) at that time?

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Tony Lindgren]

* Con Kolivas <kernel@kolivas.org> [050802 03:54]:
> On Tue, 2 Aug 2005 18:15, Tony Lindgren wrote:
> > * Con Kolivas <kernel@kolivas.org> [050802 00:36]:
> > > On Tue, 2 Aug 2005 05:17 pm, Tony Lindgren wrote:
> > > > But this you can verify by booting to single user mode and then running
> > > > pmstats 5, and if ticks is not below 25HZ, there's something in the
> > > > kernel polling.
> > >
> > > I'm removing modules and they don't seem to do anything so I'm not sure
> > > what else to try.
> >
> > If you have 130HZ in single user mode, it's some kernel driver.
> > You could printk the the next timer, then grep for that in System.map:
> 
> I kept pulling modules and eventually got to 27Hz so something was definitely 
> happening.

Cool.

> I need to ask you why you think limiting the maximum Hz is a bad idea? On a 
> laptop, say we have set the powersave governor, we have already told the 
> kernel we are interested in maximising power saving at the expense of 
> performance. Would it not be appropriate for this to be linked in a way that 
> sets maximum Hz to some value that maximises power save (whatever that value 
> is) at that time?

With dyntick the system will run at max HZ only when busy. It is possible
that cutting down max HZ might cause some savings while busy, but I would
assume the savings are minimal.

I personally prefer to have the performance available when needed, and
max savings while idle.

Tony

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Tue, 2 Aug 2005 21:31, Tony Lindgren wrote:
> * Con Kolivas <kernel@kolivas.org> [050802 03:54]:
>
> > I need to ask you why you think limiting the maximum Hz is a bad idea? On
> > a laptop, say we have set the powersave governor, we have already told
> > the kernel we are interested in maximising power saving at the expense of
> > performance. Would it not be appropriate for this to be linked in a way
> > that sets maximum Hz to some value that maximises power save (whatever
> > that value is) at that time?
>
> With dyntick the system will run at max HZ only when busy. It is possible
> that cutting down max HZ might cause some savings while busy, but I would
> assume the savings are minimal.
>
> I personally prefer to have the performance available when needed, and
> max savings while idle.

That's what I felt too but wasn't sure about the power saving. However what 
you say makes complete sense; if the machine is loaded then the extra power 
overhead of 1000 vs 100 ticks is meaningless, but throughput may be of 
concern. However I managed to get it booted on my p4 at home and while I'm 
using it under load I find it rarely gets to 1000Hz during realistic loads. 
I'll be posting a fresh patch shortly with the last few cleanups I could 
find, that I'm now running on 2.6.13-rc5.

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Avuton Olrich]

On 8/1/05, Con Kolivas <kernel@kolivas.org> wrote:
> This is a code reordered version of the dynamic ticks patch from Tony Lindgen
> and Tuukka Tikkanen - sorry about spamming your mail boxes with this, but
> thanks for the code. There is significant renewed interest by the lkml
> audience for such a feature which is why I'm butchering your code (sorry
> again if you don't like me doing this). The only real difference between your
> code and this patch is moving the #ifdef'd code out of code paths and putting
> it into dyn-tick specific files.

OK, I rolled my own patch, 2.6.13-rc4-ck1-reiser4+this patch and it
appears to be running on my desktop Asus A7N8X very well:

I am running with Local APIC/IO-APIC/APIC Timer and forceapic. Time
does not appear to be running slow, and I do not appear to have a slow
boot.

sbh@rocket ~ $ cat /sys/devices/system/timer/timer0/dyn_tick_state
suitable:       1
enabled:        1
using APIC:     1

[4294683.959000] dyn-tick: Maximum ticks to skip limited to 803
[4294683.959000] dyn-tick: Timer using dynamic tick

The nvidia driver also works, and the most unexpected thing is after a
few hours of running it seems stable :)

So, to repeat I'm only reporting sucess, I'm unsure of the power
savings but this computer is on all day.

Thanks,
avuton
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Wed, 3 Aug 2005 00:01, Avuton Olrich wrote:
> OK, I rolled my own patch, 2.6.13-rc4-ck1-reiser4+this patch and it
> appears to be running on my desktop Asus A7N8X very well:
>
> I am running with Local APIC/IO-APIC/APIC Timer and forceapic. Time
> does not appear to be running slow, and I do not appear to have a slow
> boot.

Great!

> sbh@rocket ~ $ cat /sys/devices/system/timer/timer0/dyn_tick_state
> suitable:       1
> enabled:        1
> using APIC:     1

Tony as an aside, I notice I get much lower Hz values (less than half) on my 
P4 if I'm running without using APIC although everything appears to run 
stable in either configuration. Is this expected behaviour?

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Theodore Ts'o]

On Tue, Aug 02, 2005 at 02:43:55PM +1000, Con Kolivas wrote:
> This is a code reordered version of the dynamic ticks patch from Tony Lindgen 
> and Tuukka Tikkanen - sorry about spamming your mail boxes with this, but 
> thanks for the code. There is significant renewed interest by the lkml 
> audience for such a feature which is why I'm butchering your code (sorry 
> again if you don't like me doing this). The only real difference between your 
> code and this patch is moving the #ifdef'd code out of code paths and putting 
> it into dyn-tick specific files. 
> 
> This has slightly more build fixes than the last one I posted and boots and 
> runs fine on my laptop. So far at absolute idle it appears this pentiumM 1.7 
> is claiming to have _25%_ more battery life. I'll need to investigate further 
> to see the real power savings. 

Hi Con,

I had a chance to try out your patch (2.6.13-rc4-dtck-2.patch) and
using either the APIC or PIT timer, if dynamic tick is enabled, on my
laptop, this kicks up the bus mastering activity enough so that the
processor doesn't have a chance to enter the C4 state, and stays stuck
at C2.  As a result, enabling dynamic tick _increases_ power
consumption by 20% on my T40 laptop (1.6 MHz Pentium M).  I monitored
power utilization using pmstats-0.2, and used
/proc/acpi/processor/CPU/power to monitor bus mastering activity and the CPU C-states.

As soon as I disabled dynamic tick using:

	echo 0 > /sys/devices/system/timer/timer0/dyn_tick_state

The number of ticks went up to 1024, bus mastering activity dropped to
zero, and the processor entered C4 state, and power utilization
dropped by 20%.

When I enabled dynamic tick using:

	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state

The number of ticks dropped down to 60-70 HZ, bus mastering activity
jumpped up to being almost always active, and the processor stayed
stuck at C2 state, and power utilization climbed back up by 20%.

This was on a completely idle, freshly booted machine, without X
running and just a console login.

						- Ted

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Sun, 7 Aug 2005 00:54, Theodore Ts'o wrote:
> On Tue, Aug 02, 2005 at 02:43:55PM +1000, Con Kolivas wrote:
> > This is a code reordered version of the dynamic ticks patch from Tony
> > Lindgen and Tuukka Tikkanen - sorry about spamming your mail boxes with
> > this, but thanks for the code. There is significant renewed interest by
> > the lkml audience for such a feature which is why I'm butchering your
> > code (sorry again if you don't like me doing this). The only real
> > difference between your code and this patch is moving the #ifdef'd code
> > out of code paths and putting it into dyn-tick specific files.
> >
> > This has slightly more build fixes than the last one I posted and boots
> > and runs fine on my laptop. So far at absolute idle it appears this
> > pentiumM 1.7 is claiming to have _25%_ more battery life. I'll need to
> > investigate further to see the real power savings.
>
> Hi Con,
>
> I had a chance to try out your patch (2.6.13-rc4-dtck-2.patch) and
> using either the APIC or PIT timer, if dynamic tick is enabled, on my
> laptop, this kicks up the bus mastering activity enough so that the
> processor doesn't have a chance to enter the C4 state, and stays stuck
> at C2.  As a result, enabling dynamic tick _increases_ power
> consumption by 20% on my T40 laptop (1.6 MHz Pentium M). 

Lovely! (not)

> I monitored 
> power utilization using pmstats-0.2, and used
> /proc/acpi/processor/CPU/power to monitor bus mastering activity and the
> CPU C-states.
>
> As soon as I disabled dynamic tick using:
>
> 	echo 0 > /sys/devices/system/timer/timer0/dyn_tick_state
>
> The number of ticks went up to 1024, bus mastering activity dropped to
> zero, and the processor entered C4 state, and power utilization
> dropped by 20%.
>
> When I enabled dynamic tick using:
>
> 	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
>
> The number of ticks dropped down to 60-70 HZ, bus mastering activity
> jumpped up to being almost always active,

Anyone know why this would happen?

> and the processor stayed 
> stuck at C2 state, and power utilization climbed back up by 20%.
>
> This was on a completely idle, freshly booted machine, without X
> running and just a console login.

Thanks for testing.

Cheers,
Con

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Stefan Seyfried]

Con Kolivas wrote:

>> When I enabled dynamic tick using:
>>
>> 	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
>>
>> The number of ticks dropped down to 60-70 HZ, bus mastering activity
>> jumpped up to being almost always active,
> 
> Anyone know why this would happen?

This is just a guess, without any actual code-reading:
Maybe the C-state decision process just relies on being called every
tick, so "after X ticks with no BM activity, go to next deeper C state".
As long as 1000 ticks per second are coming in, everything is fine and
we enter C[n+1] after X miliseconds without BM activity. Now if there
are only 60-70 ticks per second, you never get X ticks without BM
activity so you never go deeper than C2.

Just a guess.
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen

RE: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
>Stefan Seyfried
>Sent: Sunday, August 07, 2005 10:43 PM
>To: Con Kolivas
>Cc: tony@atomide.com; ck@vds.kolivas.org; 
>tuukka.tikkanen@elektrobit.com; linux-kernel@vger.kernel.org; 
>tytso@mit.edu
>Subject: Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)
>
>Con Kolivas wrote:
>
>>> When I enabled dynamic tick using:
>>>
>>> 	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
>>>
>>> The number of ticks dropped down to 60-70 HZ, bus mastering activity
>>> jumpped up to being almost always active,
>> 
>> Anyone know why this would happen?
>
>This is just a guess, without any actual code-reading:
>Maybe the C-state decision process just relies on being called every
>tick, so "after X ticks with no BM activity, go to next deeper 
>C state".
>As long as 1000 ticks per second are coming in, everything is fine and
>we enter C[n+1] after X miliseconds without BM activity. Now if there
>are only 60-70 ticks per second, you never get X ticks without BM
>activity so you never go deeper than C2.
>
>Just a guess.

That is correct. The C-state policy right now looks at jiffies to decide
on which C-state to go to (instead of absolute time).
This patch from Thomas should help with respect to going to proper 
C-state in presence of dynamic tick.
http://lkml.org/lkml/2005/4/19/96

Thanks,
Venki

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Pavel Machek]

Hi!

> > I monitored 
> > power utilization using pmstats-0.2, and used
> > /proc/acpi/processor/CPU/power to monitor bus mastering activity and the
> > CPU C-states.
> >
> > As soon as I disabled dynamic tick using:
> >
> > 	echo 0 > /sys/devices/system/timer/timer0/dyn_tick_state
> >
> > The number of ticks went up to 1024, bus mastering activity dropped to
> > zero, and the processor entered C4 state, and power utilization
> > dropped by 20%.
> >
> > When I enabled dynamic tick using:
> >
> > 	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
> >
> > The number of ticks dropped down to 60-70 HZ, bus mastering activity
> > jumpped up to being almost always active,
> 
> Anyone know why this would happen?

Bus mastering monitor was broken last time I checked... it depended on
HZ in ugly way or something like that. It was on ACPI mailing lists.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Thomas Renninger]

Pallipadi, Venkatesh wrote:
>>-----Original Message-----
>>From: linux-kernel-owner@vger.kernel.org 
>>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
>>Stefan Seyfried
>>Sent: Sunday, August 07, 2005 10:43 PM
>>To: Con Kolivas
>>Cc: tony@atomide.com; ck@vds.kolivas.org; 
>>tuukka.tikkanen@elektrobit.com; linux-kernel@vger.kernel.org; 
>>tytso@mit.edu
>>Subject: Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)
>>
>>Con Kolivas wrote:
>>
>>>>When I enabled dynamic tick using:
>>>>
>>>>	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
>>>>
>>>>The number of ticks dropped down to 60-70 HZ, bus mastering activity
>>>>jumpped up to being almost always active,
>>>Anyone know why this would happen?
>>This is just a guess, without any actual code-reading:
>>Maybe the C-state decision process just relies on being called every
>>tick, so "after X ticks with no BM activity, go to next deeper 
>>C state".
>>As long as 1000 ticks per second are coming in, everything is fine and
>>we enter C[n+1] after X miliseconds without BM activity. Now if there
>>are only 60-70 ticks per second, you never get X ticks without BM
>>activity so you never go deeper than C2.
>>
>>Just a guess.
> 
> That is correct. The C-state policy right now looks at jiffies to decide
> on which C-state to go to (instead of absolute time).
> This patch from Thomas should help with respect to going to proper 
> C-state in presence of dynamic tick.
> http://lkml.org/lkml/2005/4/19/96
> 
My patch considered only the average last idle times and the average last bus master
activities.
It could happen that C3/C4 comes in too fast (not waiting long enough for bus master
activity to settle down) which could result in failed transitions or misfunctionality
of bus master devices.
However, it worked on my machine and I could gain a lot of power savings.
But be prepared that your WLAN card, USB peripherie or others might behave strangely or even that
the machine freezes (if, it should freeze quite fast if idle).
I plan to have a look at x86 and x86_64 dynamic tick patches again and rewrite the C-state
patch, soon.
Any hints on updated dyn-tick patches/projects crawling around are appreciated.

Thanks,

   Thomas

Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)

[Con Kolivas]

On Wed, 10 Aug 2005 04:44 pm, Thomas Renninger wrote:
> Pallipadi, Venkatesh wrote:
> >>-----Original Message-----
> >>From: linux-kernel-owner@vger.kernel.org
> >>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of
> >>Stefan Seyfried
> >>Sent: Sunday, August 07, 2005 10:43 PM
> >>To: Con Kolivas
> >>Cc: tony@atomide.com; ck@vds.kolivas.org;
> >>tuukka.tikkanen@elektrobit.com; linux-kernel@vger.kernel.org;
> >>tytso@mit.edu
> >>Subject: Re: [patch] i386 dynamic ticks 2.6.13-rc4 (code reordered)
> >>
> >>Con Kolivas wrote:
> >>>>When I enabled dynamic tick using:
> >>>>
> >>>>	echo 1 > /sys/devices/system/timer/timer0/dyn_tick_state
> >>>>
> >>>>The number of ticks dropped down to 60-70 HZ, bus mastering activity
> >>>>jumpped up to being almost always active,
> >>>
> >>>Anyone know why this would happen?
> >>
> >>This is just a guess, without any actual code-reading:
> >>Maybe the C-state decision process just relies on being called every
> >>tick, so "after X ticks with no BM activity, go to next deeper
> >>C state".
> >>As long as 1000 ticks per second are coming in, everything is fine and
> >>we enter C[n+1] after X miliseconds without BM activity. Now if there
> >>are only 60-70 ticks per second, you never get X ticks without BM
> >>activity so you never go deeper than C2.
> >>
> >>Just a guess.
> >
> > That is correct. The C-state policy right now looks at jiffies to decide
> > on which C-state to go to (instead of absolute time).
> > This patch from Thomas should help with respect to going to proper
> > C-state in presence of dynamic tick.
> > http://lkml.org/lkml/2005/4/19/96
>
> My patch considered only the average last idle times and the average last
> bus master activities.
> It could happen that C3/C4 comes in too fast (not waiting long enough for
> bus master activity to settle down) which could result in failed
> transitions or misfunctionality of bus master devices.
> However, it worked on my machine and I could gain a lot of power savings.
> But be prepared that your WLAN card, USB peripherie or others might behave
> strangely or even that the machine freezes (if, it should freeze quite fast
> if idle).
> I plan to have a look at x86 and x86_64 dynamic tick patches again and
> rewrite the C-state patch, soon.
> Any hints on updated dyn-tick patches/projects crawling around are
> appreciated.

The most current patch for 2.6.13-rc6 is:
http://ck.kolivas.org/patches/dyn-ticks/2.6.13-rc6-dtck-1.patch
but I would recommend waiting till Srivatsa gets out the SMP/updated version 
of this code as it may be quite different and you're best working off that 
codebase.

Cheers,
Con