i386 dynamic ticks 2.6.13-rc4 (code reordered)
PATCH 1/1 i386 dynamic ticks 2.6.13-rc4 (code reordered)
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
arch/i386/Kconfig +32 -0
@@ -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---
arch/i386/kernel/Makefile +1 -0
@@ -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
arch/i386/kernel/apic.c +18 -1
@@ -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 (); }
arch/i386/kernel/dyn-tick.c +164 -0
164 lines not on this page · raw message
arch/i386/kernel/irq.c +3 -0
@@ -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 ();
arch/i386/kernel/process.c +3 -0
@@ -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 (); }
arch/i386/kernel/time.c +5 -2
@@ -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 (); }
arch/i386/kernel/timers/timer_pit.c +37 -0
@@ -148,6 +148,43 @@ static unsigned long get_offset_pit(voidreturn 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 = {
arch/i386/kernel/timers/timer_pm.c +4 -0
@@ -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 );
arch/i386/kernel/timers/timer_tsc.c +10 -0
@@ -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 ;
arch/i386/mach-default/setup.c +16 -0
@@ -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
include/asm-i386/dyn-tick.h +66 -0
66 lines not on this page · raw message
include/linux/dyn-tick.h +66 -0
66 lines not on this page · raw message
kernel/Makefile +1 -0
@@ -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 <[email protected]>, the -fno-omit-frame-pointer is
kernel/dyn-tick.c +212 -0
212 lines not on this page · raw message
Quoted 5 lines · Con Kolivas
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.
Signature · 3 lines
Michael Marineau [email protected] Oregon State University
Quoted 4 lines · Con Kolivas
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
Quoted 5 lines · Con Kolivas
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
Quoted 9 lines · Lee Revell
Quoted 5 lines · Con Kolivas
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
Quoted 8 lines · Con Kolivas
Quoted 7 lines · Lee Revell
Quoted 5 lines · Con Kolivas
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.
Quoted 4 lines
Quoted 2 lines
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
Quoted 9 lines · Lee Revell
Quoted 8 lines · Con Kolivas
Quoted 7 lines · Lee Revell
Quoted 5 lines · Con Kolivas
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 7 lines · Con Kolivas
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.
Quoted 4 lines
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?
Quoted 4 lines
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
Quoted 18 lines · Tony Lindgren
Quoted 9 lines · Lee Revell
Quoted 8 lines · Con Kolivas
Quoted 7 lines · Lee Revell
Quoted 5 lines · Con Kolivas
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.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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?
Quoted 7 lines
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.
Quoted 10 lines
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
Quoted 37 lines · Con Kolivas
Quoted 18 lines · Tony Lindgren
Quoted 9 lines · Lee Revell
Quoted 8 lines · Con Kolivas
Quoted 7 lines · Lee Revell
Quoted 5 lines · Con Kolivas
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.Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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?
Quoted 7 lines
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.
Quoted 7 lines
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)
Quoted 6 lines
Quoted 3 lines
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:
kernel/timer.c +1 -0
@@ -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
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · Con Kolivas
Quoted 3 lines · Tony Lindgren
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
Quoted 7 lines · Con Kolivas
Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Con Kolivas
Quoted 3 lines · Tony Lindgren
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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
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
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Con Kolivas
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?
Quoted 6 lines
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
Quoted 7 lines · Con Kolivas
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
Signature · 1 line
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Quoted 6 lines · Avuton Olrich
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!
Quoted 4 lines
sbh@rocket ~ $ cat
/sys/devices/system/timer/timer0/dyn_tick_statesuitable: 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
Quoted 8 lines · Con Kolivas
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.
Quoted 4 lines
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
Quoted 14 lines · Theodore Ts'o
Quoted 8 lines · Con Kolivas
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.
Quoted 4 lines
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.
Quoted 8 lines
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)
Quoted 13 lines
I monitored
power utilization using pmstats-0.2, and used/proc/acpi/processor/CPU/powerto 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_stateThe 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%.
Quoted 6 lines
When I enabled dynamic tick using:
echo 1 >
/sys/devices/system/timer/timer0/dyn_tick_stateThe 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?
Quoted 5 lines
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
Quoted 8 lines · Con Kolivas
Quoted 6 lines
When I enabled dynamic tick using:
echo 1 >
/sys/devices/system/timer/timer0/dyn_tick_stateThe 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.
Signature · 3 lines
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
Hi!
Quoted 13 lines
Quoted 13 lines
I monitored
power utilization using pmstats-0.2, and used/proc/acpi/processor/CPU/powerto 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_stateThe 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%.
Quoted 8 lines
Quoted 6 lines
When I enabled dynamic tick using:
echo 1 >
/sys/devices/system/timer/timer0/dyn_tick_stateThe 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
Signature · 1 line
if you have sharp zaurus hardware you don't need... you know my address