2.6.15-ck1

2.6.15-ck1

[Con Kolivas]

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

These are patches designed to improve system responsiveness and interactivity. 
It is configurable to any workload but the default ck patch is aimed at the 
desktop and cks is available with more emphasis on serverspace.


Apply to 2.6.15
http://ck.kolivas.org/patches/2.6/2.6.15/2.6.15-ck1/patch-2.6.15-ck1.bz2

or server version
http://ck.kolivas.org/patches/cks/patch-2.6.15-cks1.bz2

web:
http://kernel.kolivas.org
all patches:
http://ck.kolivas.org/patches/
Split patches available.


Changes from 2.6.14-ck8

Added:
 +2.6.15-dynticks-060101.patch
 +dynticks-disable_smp_config.patch
Latest version of the dynticks patch. This is proving stable and effective on 
virtually all uniprocessor machines and will benefit systems that desire 
power savings. SMP kernels (even on UP machines) still misbehave so this 
config option is not available by default for this stable kernel.


Removed:
 -smp-nice-support7.diff
SMP Nice support is now merged in the mainline kernel

 -patch-2.6.14.5.bz2
Merged


Modified:
 -2.6.14_to_staircase12.1.diff
 -sched-staircase12.1_12.2.patch
 -sched-staircase12.2_13.patch
 +sched-staircase13.2.patch
Rolled up the staircase changes and added microoptimisations

 -schedbatch2.9.diff
 +schedbatch2.10.diff
Microoptimisation

 -2614ck8-version.diff
 +2615ck1-version.patch
Version


Full patchlist:

sched-staircase13.2.patch
schedrange.diff
schedbatch2.10.diff
sched-iso3.2.patch
1g_lowmem1_i386.diff
defaultcfq.diff
isobatch_ionice2.diff
rt_ionice.diff
pdflush-tweaks.patch
hz-default_values.patch
hz-no_default_250.patch
mm-swap_prefetch-19.patch
vm-mapped.diff
vm-lots_watermark.diff
vm-background_scan-1.diff
mm-kswapd_inherit_prio.patch
mm-prio_dependant_scan.patch
mm-batch_prio.patch
2.6.15-dynticks-060101.patch
dynticks-disable_smp_config.patch
2615ck1-version.patch


Cheers,
Con

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-ck1

[Dave Jones]

On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
 >  +2.6.15-dynticks-060101.patch
 >  +dynticks-disable_smp_config.patch
 > Latest version of the dynticks patch. This is proving stable and effective on 
 > virtually all uniprocessor machines and will benefit systems that desire 
 > power savings. SMP kernels (even on UP machines) still misbehave so this 
 > config option is not available by default for this stable kernel.

I've been curious for some time if this would actually show any measurable
power savings. So I hooked up my laptop to a gizmo[1] that shows how much
power is being sucked.

both before, and after, it shows my laptop when idle is pulling 21W.
So either the savings here are <1W (My device can't measure more accurately
than a single watt), or this isn't actually buying us anything at all, or
something needs tuning.

		Dave

[1] http://www.thinkgeek.com/gadgets/electronic/7657/

Re: 2.6.15-ck1

[Dave Jones]

On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote:
 > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
 >  >  +2.6.15-dynticks-060101.patch
 >  >  +dynticks-disable_smp_config.patch
 >  > Latest version of the dynticks patch. This is proving stable and effective on 
 >  > virtually all uniprocessor machines and will benefit systems that desire 
 >  > power savings. SMP kernels (even on UP machines) still misbehave so this 
 >  > config option is not available by default for this stable kernel.
 > 
 > I've been curious for some time if this would actually show any measurable
 > power savings. So I hooked up my laptop to a gizmo[1] that shows how much
 > power is being sucked.
 > 
 > both before, and after, it shows my laptop when idle is pulling 21W.
 > So either the savings here are <1W (My device can't measure more accurately
 > than a single watt), or this isn't actually buying us anything at all, or
 > something needs tuning.

Ah interesting. It needs to be totally idle for a period of time before
anything starts to happen at all. After about a minute of doing nothing,
it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc..

Goes no lower than 18W, and only occasionally peaks above the old idle
power usage. Not bad at all.

Causing any activity at all puts it back to the 'have to wait a while
for things to start happening' state again.

		Dave

Re: 2.6.15-ck1

[Arjan van de Ven]

On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
> On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote:
>  > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
>  >  >  +2.6.15-dynticks-060101.patch
>  >  >  +dynticks-disable_smp_config.patch
>  >  > Latest version of the dynticks patch. This is proving stable and effective on 
>  >  > virtually all uniprocessor machines and will benefit systems that desire 
>  >  > power savings. SMP kernels (even on UP machines) still misbehave so this 
>  >  > config option is not available by default for this stable kernel.
>  > 
>  > I've been curious for some time if this would actually show any measurable
>  > power savings. So I hooked up my laptop to a gizmo[1] that shows how much
>  > power is being sucked.
>  > 
>  > both before, and after, it shows my laptop when idle is pulling 21W.
>  > So either the savings here are <1W (My device can't measure more accurately
>  > than a single watt), or this isn't actually buying us anything at all, or
>  > something needs tuning.
> 
> Ah interesting. It needs to be totally idle for a period of time before
> anything starts to happen at all. After about a minute of doing nothing,
> it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc..


sounds like we need some sort of profiler or benchmarker or at least a
tool that helps finding out which timers are regularly firing, with the
aim at either grouping them or trying to reduce their disturbance in
some form.

Re: 2.6.15-ck1

[Grant Coady]

On Wed, 4 Jan 2006 14:05:54 -0500, Dave Jones <davej@redhat.com> wrote:

>On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
> >  +2.6.15-dynticks-060101.patch
> >  +dynticks-disable_smp_config.patch
> > Latest version of the dynticks patch. This is proving stable and effective on 
> > virtually all uniprocessor machines and will benefit systems that desire 
> > power savings. SMP kernels (even on UP machines) still misbehave so this 
> > config option is not available by default for this stable kernel.
>
>I've been curious for some time if this would actually show any measurable
>power savings. So I hooked up my laptop to a gizmo[1] that shows how much
>power is being sucked.
>
>both before, and after, it shows my laptop when idle is pulling 21W.
>So either the savings here are <1W (My device can't measure more accurately
>than a single watt), or this isn't actually buying us anything at all, or
>something needs tuning.

Or the laptop was still recharging the battery in both cases?

Grant.

Re: 2.6.15-ck1

[Dave Jones]

On Thu, Jan 05, 2006 at 07:38:29AM +1100, Grant Coady wrote:
 > On Wed, 4 Jan 2006 14:05:54 -0500, Dave Jones <davej@redhat.com> wrote:
 > 
 > >On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
 > > >  +2.6.15-dynticks-060101.patch
 > > >  +dynticks-disable_smp_config.patch
 > > > Latest version of the dynticks patch. This is proving stable and effective on 
 > > > virtually all uniprocessor machines and will benefit systems that desire 
 > > > power savings. SMP kernels (even on UP machines) still misbehave so this 
 > > > config option is not available by default for this stable kernel.
 > >
 > >I've been curious for some time if this would actually show any measurable
 > >power savings. So I hooked up my laptop to a gizmo[1] that shows how much
 > >power is being sucked.
 > >
 > >both before, and after, it shows my laptop when idle is pulling 21W.
 > >So either the savings here are <1W (My device can't measure more accurately
 > >than a single watt), or this isn't actually buying us anything at all, or
 > >something needs tuning.
 > 
 > Or the laptop was still recharging the battery in both cases?

No, I made sure it was fully charged (and the charging light was off)
before I started tests.  I was tricked by the fact that you have to
wait a while before things start happening.

		Dave

Re: 2.6.15-ck1

[Dave Jones]

On Wed, Jan 04, 2006 at 09:33:56PM +0100, Arjan van de Ven wrote:

 > > Ah interesting. It needs to be totally idle for a period of time before
 > > anything starts to happen at all. After about a minute of doing nothing,
 > > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc..
 > 
 > 
 > sounds like we need some sort of profiler or benchmarker or at least a
 > tool that helps finding out which timers are regularly firing, with the
 > aim at either grouping them or trying to reduce their disturbance in
 > some form.

And the winner (by a *big* margin) is...

USB.

rh_timer_func() gets called quite a *lot*. (Looks like every 250ms)

cursor_timer_handler() too. *blinky blinky*

X causes lots of hits to it_real_fn()
(incidentally, the power fluctuation only happens when at the
 console. When in X, it never happens, so we're probably hitting
 this a little too often in that case).
		
lots of apps cause process_timeout to be hit frequently.

		Dave

Re: [ck] Re: 2.6.15-ck1

[Radoslaw Szkodzinski]

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

Arjan van de Ven wrote:
> On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
>
> sounds like we need some sort of profiler or benchmarker or at least a
> tool that helps finding out which timers are regularly firing, with the
> aim at either grouping them or trying to reduce their disturbance in
> some form.
> 

You mean something like a modification to timer debugging patch to
record the last time the timer fired, right?
Timertop could then detect the pattern and provide frequency, standard
deviation and other statistical data.
It would be much more expensive to test of course.

-- 
GPG Key id:  0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2

AstralStorm


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

Re: 2.6.15-ck1

[Con Kolivas]

On Thursday 05 January 2006 06:57, Dave Jones wrote:
> On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote:
>  > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
>  >  >  +2.6.15-dynticks-060101.patch
>  >  >  +dynticks-disable_smp_config.patch
>  >  > Latest version of the dynticks patch. This is proving stable and
>  >  > effective on virtually all uniprocessor machines and will benefit
>  >  > systems that desire power savings. SMP kernels (even on UP machines)
>  >  > still misbehave so this config option is not available by default for
>  >  > this stable kernel.
>  >
>  > I've been curious for some time if this would actually show any
>  > measurable power savings. So I hooked up my laptop to a gizmo[1] that
>  > shows how much power is being sucked.
>  >
>  > both before, and after, it shows my laptop when idle is pulling 21W.
>  > So either the savings here are <1W (My device can't measure more
>  > accurately than a single watt), or this isn't actually buying us
>  > anything at all, or something needs tuning.
>
> Ah interesting. It needs to be totally idle for a period of time before
> anything starts to happen at all. After about a minute of doing nothing,
> it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22
> etc..
>
> Goes no lower than 18W, and only occasionally peaks above the old idle
> power usage. Not bad at all.
>
> Causing any activity at all puts it back to the 'have to wait a while
> for things to start happening' state again.

Thanks for testing it. Indeed skipping the ticks alone does not really save 
any significant amount of power. The real chance for power savings comes from 
using this period for smarter C state programming. The other thing as you've 
noticed is that timers need to be curbed or minimised to get the maximum 
benefit and the ondemand governor alone, which unfortunately shows up as 
something not obvious in timertop, polls at 140HZ itself - fiddling with 
ondemand/ settings in sys can drop this but slows the rate at which it 
adapts.

I've basically stopped doing any development on dynticks at this time because 
I simply do not know enough about the interaction between the IO Apic and 
what is happening on SMP. The code to handle SMP seems sane, but I'll need 
outside help to cope with whatever the IO APIC is doing. UP is working fine, 
but it won't be long before truckloads of SMP laptops are here.

Cheers,
Con

Re: 2.6.15-ck1

[Con Kolivas]

On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote:
> Arjan van de Ven wrote:
> > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
> >
> > sounds like we need some sort of profiler or benchmarker or at least a
> > tool that helps finding out which timers are regularly firing, with the
> > aim at either grouping them or trying to reduce their disturbance in
> > some form.
>
> You mean something like a modification to timer debugging patch to
> record the last time the timer fired, right?
> Timertop could then detect the pattern and provide frequency, standard
> deviation and other statistical data.
> It would be much more expensive to test of course.

I don't think the timer debugging patch needs to give out any more info. The 
userspace tool should be able to do this with the amount of info the timer 
debugging patch is giving already.

Cheers,
Con

Re: 2.6.15-ck1

[Dave Jones]

On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote:
 > On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote:
 > > Arjan van de Ven wrote:
 > > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
 > > >
 > > > sounds like we need some sort of profiler or benchmarker or at least a
 > > > tool that helps finding out which timers are regularly firing, with the
 > > > aim at either grouping them or trying to reduce their disturbance in
 > > > some form.
 > >
 > > You mean something like a modification to timer debugging patch to
 > > record the last time the timer fired, right?
 > > Timertop could then detect the pattern and provide frequency, standard
 > > deviation and other statistical data.
 > > It would be much more expensive to test of course.
 > 
 > I don't think the timer debugging patch needs to give out any more info. The 
 > userspace tool should be able to do this with the amount of info the timer 
 > debugging patch is giving already.

In the absense of a pointer to a userspace tool, I found the following handy.
(It also fixes a bug where it was printing garbage as process names).

[this is just an opencoded print_address().  I would have used that but it
 printk's instead of sprintf's to a buffer which made it useless for use by seq_print]

With this, it prints output like..

cfq_idle_slice_timer+0x0/0xb3 4 0 <kthread>
...
process_timeout+0x0/0x5 1025 147 pdflush
process_timeout+0x0/0x5 1701 3 watchdog/0
it_real_fn+0x0/0x5a 1907 2309 Xorg
process_timeout+0x0/0x5 2896 2356 gdmgreeter
process_timeout+0x0/0x5 3634 1940 python
i8042_timer_func+0x0/0xb 8699 0 <no data>
rh_timer_func+0x0/0x5 16499 4

There's still 1 case though it seems where some timers get garbage printed as their ->comm
If I get motivation to hack on this some more, I'll look further into it, but
this gets me 99% of the way there.  (Actually, it's missing timers launched
on behalf of init it seems (they all have a pid of '1'.
Wonder why init hasn't got a sane ->comm though).

		Dave

diff -urpN --exclude-from=/home/davej/.exclude linux-2.6.15/kernel/timer_top.c timertop/kernel/timer_top.c
--- linux-2.6.15/kernel/timer_top.c	2006-01-04 19:20:41.000000000 -0500
+++ timertop/kernel/timer_top.c	2006-01-04 18:37:35.000000000 -0500
@@ -27,12 +27,13 @@
 #include <linux/spinlock.h>
 #include <linux/sched.h>
 #include <linux/seq_file.h>
+#include <linux/kallsyms.h>
 #include <asm/uaccess.h>
 
 #define VERSION		"Timer Top v0.9.8"
 
 struct timer_top_info {
-	unsigned int		func_pointer;
+	unsigned long		func_pointer;
 	unsigned long		counter;
 	pid_t			pid;
 	char 			comm[TASK_COMM_LEN];
@@ -88,7 +89,11 @@ int account_timer(unsigned long function
 		if ((task_info->pid > 0) && (task_info->pid < PID_MAX_LIMIT)) {
 			pid_info = task_info->pid;
 			strncpy(name, task_info->comm, sizeof(task_info->comm));
+		} else {
+			strcpy(name, "<kthread>");
 		}
+	} else {
+		strcpy(name,"<no data>");
 	}
 
 	if (update_top_info(function, pid_info))
@@ -138,12 +143,30 @@ static struct proc_dir_entry *top_info_f
 static int proc_read_top_info(struct seq_file *m, void *v)
 {
 	struct timer_top_info *top;
+	char *modname;
+	const char *name;
+	unsigned long offset, size;
+	char namebuf[KSYM_NAME_LEN+1];
+	char buffer[sizeof("%s+%#lx/%#lx [%s]") + KSYM_NAME_LEN +
+            2*(BITS_PER_LONG*3/10) + MODULE_NAME_LEN + 1];
 
 	seq_printf(m, "Function counter - %s\n", VERSION);
 
 	list_for_each_entry(top, timer_list, list) {
-		seq_printf(m, "%x %lu %d %s\n", top->func_pointer,
-			top->counter, top->pid, top->comm);
+
+		name = kallsyms_lookup(top->func_pointer, &size, &offset, &modname, namebuf);
+		if (!name)
+			sprintf(buffer, "0x%lx", top->func_pointer);
+		else {
+			if (modname)
+				sprintf(buffer, "%s+%#lx/%#lx [%s]", name, offset,
+					size, modname);
+			else
+				sprintf(buffer, "%s+%#lx/%#lx", name, offset, size);
+		}
+
+		seq_printf(m, "%s %lu %d %s\n",
+			buffer, top->counter, top->pid, top->comm ? top->comm : "<>");
 	}
 
 	if (!top_root.record)

Re: 2.6.15-ck1

[Con Kolivas]

On Thursday 05 January 2006 11:27, Dave Jones wrote:
> On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote:
>  > On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote:
>  > > Arjan van de Ven wrote:
>  > > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
>  > > >
>  > > > sounds like we need some sort of profiler or benchmarker or at least
>  > > > a tool that helps finding out which timers are regularly firing,
>  > > > with the aim at either grouping them or trying to reduce their
>  > > > disturbance in some form.
>  > >
>  > > You mean something like a modification to timer debugging patch to
>  > > record the last time the timer fired, right?
>  > > Timertop could then detect the pattern and provide frequency, standard
>  > > deviation and other statistical data.
>  > > It would be much more expensive to test of course.
>  >
>  > I don't think the timer debugging patch needs to give out any more info.
>  > The userspace tool should be able to do this with the amount of info the
>  > timer debugging patch is giving already.
>
> In the absense of a pointer to a userspace tool, I found the following
> handy. (It also fixes a bug where it was printing garbage as process
> names).

Timertop and pmstats are here:
http://ck.kolivas.org/patches/dyn-ticks/

Cheers,
Con

Re: 2.6.15-ck1

[Dave Jones]

On Thu, Jan 05, 2006 at 11:49:17AM +1100, Con Kolivas wrote:
 > On Thursday 05 January 2006 11:27, Dave Jones wrote:
 > > On Thu, Jan 05, 2006 at 11:12:51AM +1100, Con Kolivas wrote:
 > >  > On Thursday 05 January 2006 08:40, Radoslaw Szkodzinski wrote:
 > >  > > Arjan van de Ven wrote:
 > >  > > > On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
 > >  > > >
 > >  > > > sounds like we need some sort of profiler or benchmarker or at least
 > >  > > > a tool that helps finding out which timers are regularly firing,
 > >  > > > with the aim at either grouping them or trying to reduce their
 > >  > > > disturbance in some form.
 > >  > >
 > >  > > You mean something like a modification to timer debugging patch to
 > >  > > record the last time the timer fired, right?
 > >  > > Timertop could then detect the pattern and provide frequency, standard
 > >  > > deviation and other statistical data.
 > >  > > It would be much more expensive to test of course.
 > >  >
 > >  > I don't think the timer debugging patch needs to give out any more info.
 > >  > The userspace tool should be able to do this with the amount of info the
 > >  > timer debugging patch is giving already.
 > >
 > > In the absense of a pointer to a userspace tool, I found the following
 > > handy. (It also fixes a bug where it was printing garbage as process
 > > names).
 > 
 > Timertop and pmstats are here:
 > http://ck.kolivas.org/patches/dyn-ticks/

me no likee.  it's very pretty, but it feels awkward to drive.
Even after I'd stopped it dancing long enough to read, its
output format seemed odd.

With the diff I did, I just piped it through sort -n -k2 | tail
to see the interesting parts.

		Dave

Re: 2.6.15-ck1

[Andi Kleen]

Arjan van de Ven <arjan@infradead.org> writes:


> sounds like we need some sort of profiler or benchmarker or at least a
> tool that helps finding out which timers are regularly firing, with the
> aim at either grouping them or trying to reduce their disturbance in
> some form.

I did one some time ago for my own noidletick patch. Can probably dig
it out again. It just profiled which timers interrupted idle.

Executive summary for my laptop: worst was the keyboard driver (it ran
some polling driver to work around some hardware bug, but fired very
often) , followed by the KDE desktop (should be mostly
fixed now, I complained) and the X server and some random kernel 
drivers.

I haven't checked recently if keyboard has been fixed by now.

-Andi

Re: 2.6.15-ck1

[Con Kolivas]

On Thu, 5 Jan 2006 12:22 pm, Andi Kleen wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> > sounds like we need some sort of profiler or benchmarker or at least a
> > tool that helps finding out which timers are regularly firing, with the
> > aim at either grouping them or trying to reduce their disturbance in
> > some form.
>
> I did one some time ago for my own noidletick patch. Can probably dig
> it out again. It just profiled which timers interrupted idle.
>
> Executive summary for my laptop: worst was the keyboard driver (it ran
> some polling driver to work around some hardware bug, but fired very
> often) , followed by the KDE desktop (should be mostly
> fixed now, I complained) and the X server and some random kernel
> drivers.
>
> I haven't checked recently if keyboard has been fixed by now.

I checked with Vojtech some time ago and he said we could change the polling 
from HZ/20 to about HZ/5 which I have included in the rolled up dynticks 
patch already. Not that 20 HZ is very frequent, but anything that splits up 
timer intervals potentially by 20 more adds up.

Cheers,
Con

Re: 2.6.15-ck1

[Tony Lindgren]

* Arjan van de Ven <arjan@infradead.org> [060104 12:34]:
> On Wed, 2006-01-04 at 14:57 -0500, Dave Jones wrote:
> > On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote:
> >  > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
> >  >  >  +2.6.15-dynticks-060101.patch
> >  >  >  +dynticks-disable_smp_config.patch
> >  >  > Latest version of the dynticks patch. This is proving stable and effective on 
> >  >  > virtually all uniprocessor machines and will benefit systems that desire 
> >  >  > power savings. SMP kernels (even on UP machines) still misbehave so this 
> >  >  > config option is not available by default for this stable kernel.
> >  > 
> >  > I've been curious for some time if this would actually show any measurable
> >  > power savings. So I hooked up my laptop to a gizmo[1] that shows how much
> >  > power is being sucked.
> >  > 
> >  > both before, and after, it shows my laptop when idle is pulling 21W.
> >  > So either the savings here are <1W (My device can't measure more accurately
> >  > than a single watt), or this isn't actually buying us anything at all, or
> >  > something needs tuning.
> > 
> > Ah interesting. It needs to be totally idle for a period of time before
> > anything starts to happen at all. After about a minute of doing nothing,
> > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22 etc..
> 
> 
> sounds like we need some sort of profiler or benchmarker or at least a
> tool that helps finding out which timers are regularly firing, with the
> aim at either grouping them or trying to reduce their disturbance in
> some form.

Take a look at timertop for that.

Tony

Re: 2.6.15-ck1

[Tony Lindgren]

* Con Kolivas <kernel@kolivas.org> [060104 15:23]:
> On Thursday 05 January 2006 06:57, Dave Jones wrote:
> > On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote:
> >  > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
> >  >  >  +2.6.15-dynticks-060101.patch
> >  >  >  +dynticks-disable_smp_config.patch
> >  >  > Latest version of the dynticks patch. This is proving stable and
> >  >  > effective on virtually all uniprocessor machines and will benefit
> >  >  > systems that desire power savings. SMP kernels (even on UP machines)
> >  >  > still misbehave so this config option is not available by default for
> >  >  > this stable kernel.
> >  >
> >  > I've been curious for some time if this would actually show any
> >  > measurable power savings. So I hooked up my laptop to a gizmo[1] that
> >  > shows how much power is being sucked.
> >  >
> >  > both before, and after, it shows my laptop when idle is pulling 21W.
> >  > So either the savings here are <1W (My device can't measure more
> >  > accurately than a single watt), or this isn't actually buying us
> >  > anything at all, or something needs tuning.
> >
> > Ah interesting. It needs to be totally idle for a period of time before
> > anything starts to happen at all. After about a minute of doing nothing,
> > it started to fluctuate once a second 20,21,19,20,19,20,18,21,19,20,22
> > etc..
> >
> > Goes no lower than 18W, and only occasionally peaks above the old idle
> > power usage. Not bad at all.
> >
> > Causing any activity at all puts it back to the 'have to wait a while
> > for things to start happening' state again.
> 
> Thanks for testing it. Indeed skipping the ticks alone does not really save 
> any significant amount of power. The real chance for power savings comes from 
> using this period for smarter C state programming. The other thing as you've 
> noticed is that timers need to be curbed or minimised to get the maximum 
> benefit and the ondemand governor alone, which unfortunately shows up as 
> something not obvious in timertop, polls at 140HZ itself - fiddling with 
> ondemand/ settings in sys can drop this but slows the rate at which it 
> adapts.

Device specific power states will help with getting power savings too.

Tony

Re: 2.6.15-ck1

[Dave Jones]

On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote:
 > Arjan van de Ven <arjan@infradead.org> writes:
 > 
 > 
 > > sounds like we need some sort of profiler or benchmarker or at least a
 > > tool that helps finding out which timers are regularly firing, with the
 > > aim at either grouping them or trying to reduce their disturbance in
 > > some form.
 > 
 > I did one some time ago for my own noidletick patch. Can probably dig
 > it out again. It just profiled which timers interrupted idle.
 > 
 > Executive summary for my laptop: worst was the keyboard driver (it ran
 > some polling driver to work around some hardware bug, but fired very
 > often) , followed by the KDE desktop (should be mostly
 > fixed now, I complained) and the X server and some random kernel 
 > drivers.
 > 
 > I haven't checked recently if keyboard has been fixed by now.

it was a little further down the list from the others I posted,
but it is still there fairly high in the list of offenders,
even though I wasn't touching keyboard/mouse (in fact, it was several feet
away from me, I had ssh'd to it for tests).

		Dave

Re: 2.6.15-ck1

[Vojtech Pavlik]

On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> 
> 
> > sounds like we need some sort of profiler or benchmarker or at least a
> > tool that helps finding out which timers are regularly firing, with the
> > aim at either grouping them or trying to reduce their disturbance in
> > some form.
> 
> I did one some time ago for my own noidletick patch. Can probably dig
> it out again. It just profiled which timers interrupted idle.
> 
> Executive summary for my laptop: worst was the keyboard driver (it ran
> some polling driver to work around some hardware bug, but fired very
> often) , followed by the KDE desktop (should be mostly
> fixed now, I complained) and the X server and some random kernel 
> drivers.
> 
> I haven't checked recently if keyboard has been fixed by now.

It's not. At this moment it's impossible to remove without significant
surgery to the driver, because it'd prevent hotplugging and many KVMs
from working.

I can rather easily make the timer frequency variable. Would be 1 second
idle ticks OK? 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ck] Re: 2.6.15-ck1

[Con Kolivas]

On Thursday 05 January 2006 17:42, Vojtech Pavlik wrote:
> On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote:
> > Arjan van de Ven <arjan@infradead.org> writes:
> > > sounds like we need some sort of profiler or benchmarker or at least a
> > > tool that helps finding out which timers are regularly firing, with the
> > > aim at either grouping them or trying to reduce their disturbance in
> > > some form.
> >
> > I did one some time ago for my own noidletick patch. Can probably dig
> > it out again. It just profiled which timers interrupted idle.
> >
> > Executive summary for my laptop: worst was the keyboard driver (it ran
> > some polling driver to work around some hardware bug, but fired very
> > often) , followed by the KDE desktop (should be mostly
> > fixed now, I complained) and the X server and some random kernel
> > drivers.
> >
> > I haven't checked recently if keyboard has been fixed by now.
>
> It's not. At this moment it's impossible to remove without significant
> surgery to the driver, because it'd prevent hotplugging and many KVMs
> from working.
>
> I can rather easily make the timer frequency variable. Would be 1 second
> idle ticks OK?

Sure. The lower the better, and HZ with dynticks bottoms out at 14HZ.

Cheers,
Con

Re: 2.6.15-ck1

[Andi Kleen]

On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote:

> > I haven't checked recently if keyboard has been fixed by now.
> 
> It's not. At this moment it's impossible to remove without significant
> surgery to the driver, because it'd prevent hotplugging and many KVMs
> from working.

Sorry? You say you can't do hot plugging in the keyboard driver
without a polling timer? 

That sounds quite bogus to me. A zillion other OS do keyboards
fine without polling timers.

-Andi

Re: 2.6.15-ck1

[Vojtech Pavlik]

On Thu, Jan 05, 2006 at 04:19:16PM +0100, Andi Kleen wrote:
> On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote:
> 
> > > I haven't checked recently if keyboard has been fixed by now.
> > 
> > It's not. At this moment it's impossible to remove without significant
> > surgery to the driver, because it'd prevent hotplugging and many KVMs
> > from working.
> 
> Sorry? You say you can't do hot plugging in the keyboard driver
> without a polling timer? 
> 
> That sounds quite bogus to me. A zillion other OS do keyboards
> fine without polling timers.
 
I can either have the polling timer, or the IRQs acquired all the time.
The later needs significant changes to the driver - I currently enable
the IRQs only if a device is present.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: 2.6.15-ck1

[Andi Kleen]

On Thursday 05 January 2006 17:30, Vojtech Pavlik wrote:
> On Thu, Jan 05, 2006 at 04:19:16PM +0100, Andi Kleen wrote:
> > On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote:
> > 
> > > > I haven't checked recently if keyboard has been fixed by now.
> > > 
> > > It's not. At this moment it's impossible to remove without significant
> > > surgery to the driver, because it'd prevent hotplugging and many KVMs
> > > from working.
> > 
> > Sorry? You say you can't do hot plugging in the keyboard driver
> > without a polling timer? 
> > 
> > That sounds quite bogus to me. A zillion other OS do keyboards
> > fine without polling timers.
>  
> I can either have the polling timer, or the IRQs acquired all the time.
> The later needs significant changes to the driver - I currently enable
> the IRQs only if a device is present.

You mean you run the timer to avoid aquiring the interrupt early? 

-Andi

Re: 2.6.15-ck1

[Dmitry Torokhov]

On 1/5/06, Andi Kleen <ak@suse.de> wrote:
> On Thursday 05 January 2006 17:30, Vojtech Pavlik wrote:
> > On Thu, Jan 05, 2006 at 04:19:16PM +0100, Andi Kleen wrote:
> > > On Thursday 05 January 2006 07:42, Vojtech Pavlik wrote:
> > >
> > > > > I haven't checked recently if keyboard has been fixed by now.
> > > >
> > > > It's not. At this moment it's impossible to remove without significant
> > > > surgery to the driver, because it'd prevent hotplugging and many KVMs
> > > > from working.
> > >
> > > Sorry? You say you can't do hot plugging in the keyboard driver
> > > without a polling timer?
> > >
> > > That sounds quite bogus to me. A zillion other OS do keyboards
> > > fine without polling timers.
> >
> > I can either have the polling timer, or the IRQs acquired all the time.
> > The later needs significant changes to the driver - I currently enable
> > the IRQs only if a device is present.
>
> You mean you run the timer to avoid aquiring the interrupt early?
>

Yes, until some driver claims serio port interrupt is not acquired and
thus available for others.

I would say we could bump the timer as high as 5 seconds for
hotplugging. It may give delay with some KVMs, but only first time you
switch to the box in question.

--
Dmitry

Re: 2.6.15-ck1

[Andi Kleen]

On Thursday 05 January 2006 18:13, Dmitry Torokhov wrote:

> Yes, until some driver claims serio port interrupt is not acquired and
> thus available for others.
> 
> I would say we could bump the timer as high as 5 seconds for
> hotplugging. It may give delay with some KVMs, but only first time you
> switch to the box in question.

I would say you just should aquire the interrupt always. Running
a timer instead of just using the perfectly fine interrupt looks simply like 
a design bug, not a feature.

-Andi

Re: 2.6.15-ck1

[Tomasz Torcz]

On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
> Added:
>  +2.6.15-dynticks-060101.patch

  On practically unused (booted and logged in into GNOME, one terminal
emulator, clock gdesklet ticking) desktop system -- Sempron 2500+,
pmstats show between 450 and 600 Hz. Is this normal?

-- 
Tomasz Torcz                Only gods can safely risk perfection,
zdzichu@irc.-nie.spam-.pl     it's a dangerous thing for a man.  -- Alia

Re: [ck] Re: 2.6.15-ck1

[Kevin Radloff]

On 1/4/06, Con Kolivas <kernel@kolivas.org> wrote:
> Thanks for testing it. Indeed skipping the ticks alone does not really save
> any significant amount of power. The real chance for power savings comes from
> using this period for smarter C state programming. The other thing as you've
> noticed is that timers need to be curbed or minimised to get the maximum
> benefit and the ondemand governor alone, which unfortunately shows up as
> something not obvious in timertop, polls at 140HZ itself - fiddling with
> ondemand/ settings in sys can drop this but slows the rate at which it
> adapts.

For what it's worth (and I haven't done any actual power usage tests),
on my 1.1GHz Pentium M laptop the gkrellm CPU speed meter
(gkrellm-x86info) shows the CPU going down to around 30MHz thanks to
the recent C-state patches (speeds under the minimum of 600MHz reflect
C3 usage). On the other hand, without dynticks the speed hangs out
around 60MHz, which as far as I know reflects the maximum possible C3
usage with HZ = 1000. So really I'm guessing that the difference in
power consumption isn't really improved much, given that on my Pentium
M idle time is spent in C2, and if C3 is possible it's used quite
extensively regardless.

Of course, this may point to who the people who could really benefit
from dynticks are--those with long latencies for higher C states. But
in that sense, dynticks would seem to be of use more for legacy
systems, since everyone is moving towards CPUs with better
power-saving capabilities, no? I'm not knowledgeable about the
specifics.. just thinking out loud, really. ;)

Perhaps fixing the biggest offenders of timer (mis?)use would benefit
everyone all-around. I haven't really been able to identify who those
are though, given the lack of sorting in timertop and its
seemingly-haphazard ordering of data (or is it there and I've missed
it?).

--
Kevin 'radsaq' Radloff
radsaq@gmail.com
http://thesaq.com/

Re: 2.6.15-ck1

[Con Kolivas]

On Fri, 6 Jan 2006 04:58 am, Tomasz Torcz wrote:
> On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
> > Added:
> >  +2.6.15-dynticks-060101.patch
>
>   On practically unused (booted and logged in into GNOME, one terminal
> emulator, clock gdesklet ticking) desktop system -- Sempron 2500+,
> pmstats show between 450 and 600 Hz. Is this normal?

Chances are your hardware is one that doesn't play well with dynticks then. 
Compile in the timer info and use the timertop utility to see if there really 
is something increasing your timer activity to 450HZ and if there isn't then 
it's a problem with dynticks and your hardware. This is the problem I'm 
currently seeing on SMP configs (too many HZ) and I have yet to figure out 
what it is about the IO APIC that makes this happen.

Cheers,
Con

Re: 2.6.15-ck1

[Tomasz Torcz]

[-- Attachment #1.1: Type: text/plain, Size: 3622 bytes --]

On Fri, Jan 06, 2006 at 10:22:45AM +1100, Con Kolivas wrote:
> On Fri, 6 Jan 2006 04:58 am, Tomasz Torcz wrote:
> > On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
> > > Added:
> > >  +2.6.15-dynticks-060101.patch
> >
> >   On practically unused (booted and logged in into GNOME, one terminal
> > emulator, clock gdesklet ticking) desktop system -- Sempron 2500+,
> > pmstats show between 450 and 600 Hz. Is this normal?
> 
> Chances are your hardware is one that doesn't play well with dynticks then. 

  Let me elaborate. Hardware is desktop system, nforce2 chipset based
UP motherboard. CPU is Sempron 2500+. SATA disk, matrox card with fbcon,
Intel e1000 networking.

> Compile in the timer info and use the timertop utility to see if there really 
> is something increasing your timer activity to 450HZ and if there isn't then 
> it's a problem with dynticks and your hardware. This is the problem I'm 
> currently seeing on SMP configs (too many HZ) and I have yet to figure out 
> what it is about the IO APIC that makes this happen.

 Typical output look like:

 Timer Top v 0.9.8
 Ticks:  470      Period: 1 s (Up/Dn)      Skip Low Hz(z): Y      Clear(c)
 PID           Command   Freq(Hz)   Count           Function       Address 
10946          timertop        1       14   process_timeout        c0121e08
 4480   netspeed_applet        1       52   process_timeout        c0121e08
 4132        gam_server       35     2011   process_timeout        c0121e08
 4321            python       47     2751   process_timeout        c0121e08
 5614             mrxvt        1      196   process_timeout        c0121e08
 4486              mono        9      531   process_timeout        c0121e08
 3605                 X       16     1137   it_real_fn             c011deff
 4463     mixer_applet2       10      526   process_timeout        c0121e08
   18                --        4      210   (module)               e2a3409b
 9936              ekg2        2      104   process_timeout        c0121e08
 5257             mrxvt        3      175   process_timeout        c0121e08
    0                 -        3      250   i8042_timer_func       c0230f2b
10139         powernowd        1       56   process_timeout        c0121e08
    0                 -        1       10   (module)               c1a13ed0
10705             mrxvt        2      168   process_timeout        c0121e08
 4485   multiload-apple        3      190   process_timeout        c0121e08
 5194        postmaster        4      290   process_timeout        c0121e08
    0                 -        2      126   (module)               cf85af40
    0                 -        1       46   neigh_periodic_time    c02a474a
 3511              ntpd        1       54   it_real_fn             c011deff
 4561              mono        2      108   process_timeout        c0121e08
    3        watchdog/0        1       56   process_timeout        c0121e08
 5247              tail        1       57   process_timeout        c0121e08

  gam_server uses inotify, but regardless polls some socket very
frequently. Python process is driving gDesklets, two of them are
updating every second -- a clock and disk bandwidth meter. mixer_applet
is doing someting stupid, but GNOME developers are aware of problem.

  I'm attaching:
  - dmesg from vanilla 2.6.15
  - dmesg from 2.6.15-ck1
  - .config from 2.6.15-ck1

  Hope this helps somehow to locate the problem.

-- 
Tomasz Torcz                 "God, root, what's the difference?"
zdzichu@irc.-nie.spam-.pl         "God is more forgiving."


[-- Attachment #1.2: config.gz --]
[-- Type: application/x-gunzip, Size: 10947 bytes --]

[-- Attachment #1.3: dmesg-2.6.15 --]
[-- Type: text/plain, Size: 13228 bytes --]

Linux version 2.6.15 (zdzichu@mother) (gcc version 3.4.5) #50 Tue Jan 3 15:46:54 CET 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
 BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131056
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 126960 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:0
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia                                ) @ 0x000f6b00
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff79c0
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Built 1 zonelists
Kernel command line: ro resume=/dev/sda2 video=matroxfb:vesa:0x11A
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
CPU 0 irqstacks, hard=c0408000 soft=c0407000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 1747.095 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 513972k/524224k available (2114k kernel code, 9696k reserved, 788k data, 172k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3497.64 BogoMIPS (lpj=6995291)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: AMD Sempron(tm) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
checking if image is initramfs... it is
Freeing initrd memory: 1380k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb420, last bus=2
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: nForce2 C1 Halt Disconnect fixup
Boot video device is 0000:02:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled.
ACPI: PCI Interrupt Link [APCE] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled.
Generic PHY: Registered new driver
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:08.0
  IO window: 9000-afff
  MEM window: e9000000-eaffffff
  PREFETCH window: 30000000-300fffff
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: e6000000-e8ffffff
  PREFETCH window: e4000000-e5ffffff
PCI: Setting latency timer of device 0000:00:08.0 to 64
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1136538385.208:1): initialized
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 16
matroxfb: Matrox G550 detected
PInS memtype = 5
matroxfb: MTRR's turned on
matroxfb: 1280x1024x16bpp (virtual: 1280x6553)
matroxfb: framebuffer at 0xE4000000, mapped to 0xe0880000, size 33554432
Console: switching to colour frame buffer device 160x64
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: Thermal Zone [THRM] (32 C)
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected NVIDIA nForce2 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
LXT970: Registered new driver
LXT971: Registered new driver
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Linux video capture interface: v1.00
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE2: IDE controller at PCI slot 0000:00:09.0
NFORCE2: chipset revision 162
NFORCE2: not 100% native mode: will probe irqs later
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
libata version 1.20 loaded.
sata_sil 0000:01:0b.0: version 0.9
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [APC3] -> GSI 18 (level, high) -> IRQ 17
ata1: SATA max UDMA/100 cmd 0xE081C080 ctl 0xE081C08A bmdma 0xE081C000 irq 17
ata2: SATA max UDMA/100 cmd 0xE081C0C0 ctl 0xE081C0CA bmdma 0xE081C008 irq 17
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata1(0): applying Seagate errata fix
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: no device found (phy stat 00000000)
scsi1 : sata_sil
  Vendor: ATA       Model: ST3200822AS       Rev: 3.01
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3
sd 0:0:0:0: Attached scsi disk sda
mice: PS/2 mouse device common for all mice
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
ALSA device list:
  No soundcards found.
NET: Registered protocol family 2
input: AT Translated Set 2 keyboard as /class/input/input0
IP route cache hash table entries: 8192 (order: 3, 32768 bytes)
TCP established hash table entries: 32768 (order: 5, 131072 bytes)
TCP bind hash table entries: 32768 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
ip_conntrack version 2.4 (4095 buckets, 32760 max) - 212 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
powernow-k8: Processor cpuid 681 not supported
Using IPI Shortcut mode
ACPI wakeup devices: 
HUB0 HUB1 USB0 USB1 USB2 F139 MMAC MMCI UAR1 
ACPI: (supports S0 S3 S4 S5)
Freeing unused kernel memory: 172k freed
ReiserFS: dm-3: found reiserfs format "3.6" with standard journal
ReiserFS: dm-3: using ordered data mode
ReiserFS: dm-3: journal params: device dm-3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-3: checking transaction log (dm-3)
ReiserFS: dm-3: Using r5 hash to sort names
Adding 996020k swap on /dev/sda2.  Priority:2 extents:1 across:996020k
cdrom: open failed.
bttv: driver version 0.9.16 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
cpufreq: Detected nForce2 chipset revision C1
cpufreq: FSB changing is maybe unstable and can lead to crashes and data loss.
cpufreq: FSB currently at 165 MHz, FID 10.5
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
cdrom: open failed.
ReiserFS: dm-1: found reiserfs format "3.6" with standard journal
ReiserFS: dm-1: using ordered data mode
ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-1: checking transaction log (dm-1)
ReiserFS: dm-1: Using r5 hash to sort names
ReiserFS: dm-2: found reiserfs format "3.6" with standard journal
ReiserFS: dm-2: using journaled data mode
ReiserFS: dm-2: journal params: device dm-2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-2: checking transaction log (dm-2)
ReiserFS: dm-2: Using r5 hash to sort names

[-- Attachment #1.4: dmesg-2.6.15-ck1 --]
[-- Type: text/plain, Size: 13460 bytes --]

Linux version 2.6.15-ck1 (zdzichu@mother) (gcc version 3.4.5) #51 Thu Jan 5 18:40:03 CET 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
 BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
On node 0 totalpages: 131056
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 126960 pages, LIFO batch:31
  HighMem zone: 0 pages, LIFO batch:0
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia                                ) @ 0x000f6b00
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff79c0
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:dec00000)
Built 1 zonelists
Kernel command line: ro resume=/dev/sda2 video=matroxfb:vesa:0x11A
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
CPU 0 irqstacks, hard=c040a000 soft=c0409000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Using 3579 PM timer ticks per jiffy 
Detected 1747.251 MHz processor.
Using pmtmr for high-res timesource
dyn-tick: Found suitable timer: pmtmr
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 513964k/524224k available (2118k kernel code, 9704k reserved, 792k data, 172k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3496.14 BogoMIPS (lpj=1748073)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: AMD Sempron(tm) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
checking if image is initramfs... it is
Freeing initrd memory: 1380k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb420, last bus=2
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: nForce2 C1 Halt Disconnect fixup
Boot video device is 0000:02:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs *19), disabled.
ACPI: PCI Interrupt Link [APCE] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled.
Generic PHY: Registered new driver
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:08.0
  IO window: 9000-afff
  MEM window: e9000000-eaffffff
  PREFETCH window: 30000000-300fffff
PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: e6000000-e8ffffff
  PREFETCH window: e4000000-e5ffffff
PCI: Setting latency timer of device 0000:00:08.0 to 64
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1136633499.911:1): initialized
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [APC4] -> GSI 19 (level, high) -> IRQ 16
matroxfb: Matrox G550 detected
PInS memtype = 5
matroxfb: MTRR's turned on
matroxfb: 1280x1024x16bpp (virtual: 1280x6553)
matroxfb: framebuffer at 0xE4000000, mapped to 0xe0880000, size 33554432
Console: switching to colour frame buffer device 160x64
fb0: MATROX frame buffer device
matroxfb_crtc2: secondary head of fb0 was registered as fb1
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: Thermal Zone [THRM] (31 C)
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected NVIDIA nForce2 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
LXT970: Registered new driver
LXT971: Registered new driver
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Linux video capture interface: v1.00
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE2: IDE controller at PCI slot 0000:00:09.0
NFORCE2: chipset revision 162
NFORCE2: not 100% native mode: will probe irqs later
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: _NEC DVD_RW ND-3540A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
libata version 1.20 loaded.
sata_sil 0000:01:0b.0: version 0.9
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [APC3] -> GSI 18 (level, high) -> IRQ 17
ata1: SATA max UDMA/100 cmd 0xE081C080 ctl 0xE081C08A bmdma 0xE081C000 irq 17
ata2: SATA max UDMA/100 cmd 0xE081C0C0 ctl 0xE081C0CA bmdma 0xE081C008 irq 17
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata1(0): applying Seagate errata fix
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: no device found (phy stat 00000000)
scsi1 : sata_sil
  Vendor: ATA       Model: ST3200822AS       Rev: 3.01
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3
sd 0:0:0:0: Attached scsi disk sda
mice: PS/2 mouse device common for all mice
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
ALSA device list:
  No soundcards found.
NET: Registered protocol family 2
IP route cache hash table entries: 8192 (order: 3, 32768 bytes)
TCP established hash table entries: 32768 (order: 5, 131072 bytes)
TCP bind hash table entries: 32768 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
ip_conntrack version 2.4 (4095 buckets, 32760 max) - 212 bytes per conntrack
input: AT Translated Set 2 keyboard as /class/input/input0
ip_tables: (C) 2000-2002 Netfilter core team
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Bridge firewalling registered
powernow-k8: Processor cpuid 681 not supported
Using IPI Shortcut mode
dyn-tick: Disabling APIC timer, using PIT reprogramming
dyn-tick: Maximum ticks to skip limited to 54
dyn-tick: Enabling dynamic tick timer v060101
ACPI wakeup devices: 
HUB0 HUB1 USB0 USB1 USB2 F139 MMAC MMCI UAR1 
ACPI: (supports S0 S3 S4 S5)
Freeing unused kernel memory: 172k freed
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
ReiserFS: dm-3: found reiserfs format "3.6" with standard journal
ReiserFS: dm-3: using ordered data mode
ReiserFS: dm-3: journal params: device dm-3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-3: checking transaction log (dm-3)
ReiserFS: dm-3: Using r5 hash to sort names
Adding 996020k swap on /dev/sda2.  Priority:2 extents:1 across:996020k
cdrom: open failed.
bttv: driver version 0.9.16 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
cpufreq: Detected nForce2 chipset revision C1
cpufreq: FSB changing is maybe unstable and can lead to crashes and data loss.
cpufreq: FSB currently at 166 MHz, FID 10.5
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
cdrom: open failed.
ReiserFS: dm-1: found reiserfs format "3.6" with standard journal
ReiserFS: dm-1: using ordered data mode
ReiserFS: dm-1: journal params: device dm-1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-1: checking transaction log (dm-1)
ReiserFS: dm-1: Using r5 hash to sort names
ReiserFS: dm-2: found reiserfs format "3.6" with standard journal
ReiserFS: dm-2: using journaled data mode
ReiserFS: dm-2: journal params: device dm-2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-2: checking transaction log (dm-2)
ReiserFS: dm-2: Using r5 hash to sort names

[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: [ck] Re: 2.6.15-ck1

[Daniel Petrini]

On 1/5/06, Kevin Radloff <radsaq@gmail.com> wrote:
> On 1/4/06, Con Kolivas <kernel@kolivas.org> wrote:
>
> Perhaps fixing the biggest offenders of timer (mis?)use would benefit
> everyone all-around. I haven't really been able to identify who those
> are though, given the lack of sorting in timertop and its
> seemingly-haphazard ordering of data (or is it there and I've missed
> it?).
>

Timertop itself tries to not steals to much cpu whereas tries to be
less intrusive as possible. So ordering is not available yet.
But one can have a backgroud aquisition of data using:

timertop -t 50

There will be 50 s of aquisition saved in a text file so that you can
do some post-processing and order it properly.


Daniel Petrini
--
INdT - Manaus

Re: 2.6.15-ck1

[Adam Belay]

On Wed, Jan 04, 2006 at 02:05:54PM -0500, Dave Jones wrote:
> On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
>  >  +2.6.15-dynticks-060101.patch
>  >  +dynticks-disable_smp_config.patch
>  > Latest version of the dynticks patch. This is proving stable and effective on 
>  > virtually all uniprocessor machines and will benefit systems that desire 
>  > power savings. SMP kernels (even on UP machines) still misbehave so this 
>  > config option is not available by default for this stable kernel.
> 
> I've been curious for some time if this would actually show any measurable
> power savings. So I hooked up my laptop to a gizmo[1] that shows how much
> power is being sucked.
> 
> both before, and after, it shows my laptop when idle is pulling 21W.
> So either the savings here are <1W (My device can't measure more accurately
> than a single watt), or this isn't actually buying us anything at all, or
> something needs tuning.
> 
> 		Dave

I've done quite a bit of testing with dynticks and various c-state strategies.
On my thinkpad T42, dynticks can save about .5 W (as read from the ACPI battery
interface, but hey it's a good ballpark measurement).  This is when compared to
250HZ and the stock ACPI c-state code.  Both tests were running at the lowest
processor frequency (600 MHZ).  The savings were much greater when running at
1.7 GHZ or when comparing to a HZ value of 1000.  Also the advantage was closer
to 1 W when X was not running.

It might be possible to do even a little better.  Currently, I'm developing a
new ACPI idle policy that tries to take advantage of the long time we may
be able to spend in a C3 state.

Thanks,
Adam

Re: 2.6.15-ck1

[Dave Jones]

On Thu, Jan 12, 2006 at 05:11:33PM -0500, Adam Belay wrote:
 
 > > I've been curious for some time if this would actually show any measurable
 > > power savings. So I hooked up my laptop to a gizmo[1] that shows how much
 > > power is being sucked.
 > > 
 > > both before, and after, it shows my laptop when idle is pulling 21W.
 > > So either the savings here are <1W (My device can't measure more accurately
 > > than a single watt), or this isn't actually buying us anything at all, or
 > > something needs tuning.
 > 
 > I've done quite a bit of testing with dynticks and various c-state strategies.
 > On my thinkpad T42, dynticks can save about .5 W (as read from the ACPI battery
 > interface, but hey it's a good ballpark measurement).

In the follow-ups to my above message, I found that it was actually
working, and dropped from 21W down to as low as 18W in some cases, but
USB and the input layer are firing off timers very regularly, so it
bounces around all over the place.

 > It might be possible to do even a little better.  Currently, I'm developing a
 > new ACPI idle policy that tries to take advantage of the long time we may
 > be able to spend in a C3 state.

As soon as that usb timer hits (every 250ms iirc) you'll bounce back out
of any low-power state you may be in. It's a bit craptastic that we do
this, even if we don't have any USB devices plugged in.

		Dave

Re: 2.6.15-ck1

[Adam Belay]

On Thu, Jan 12, 2006 at 06:03:15PM -0500, Dave Jones wrote:
> On Thu, Jan 12, 2006 at 05:11:33PM -0500, Adam Belay wrote:
>  > It might be possible to do even a little better.  Currently, I'm developing a
>  > new ACPI idle policy that tries to take advantage of the long time we may
>  > be able to spend in a C3 state.
> 
> As soon as that usb timer hits (every 250ms iirc) you'll bounce back out
> of any low-power state you may be in. It's a bit craptastic that we do
> this, even if we don't have any USB devices plugged in.
> 
> 		Dave

I agree that's annoying, but isn't 250ms not often enough to make any
significant difference as far as power management is concerned?
Generally some bus master activity will come along in a shorter time frame,
causing a jump out of C3.

Thanks,
Adam

Re: 2.6.15-ck1

[Dave Jones]

On Thu, Jan 12, 2006 at 07:42:36PM -0500, Adam Belay wrote:

 > > > It might be possible to do even a little better.  Currently, I'm developing a
 > > > new ACPI idle policy that tries to take advantage of the long time we may
 > > > be able to spend in a C3 state.
 > > 
 > > As soon as that usb timer hits (every 250ms iirc) you'll bounce back out
 > > of any low-power state you may be in. It's a bit craptastic that we do
 > > this, even if we don't have any USB devices plugged in.
 > 
 > I agree that's annoying, but isn't 250ms not often enough to make any
 > significant difference as far as power management is concerned?
 > Generally some bus master activity will come along in a shorter time frame,
 > causing a jump out of C3.

All I know is that when I removed the usb modules, the power usage stopped
fluctuating as often, and it spent longer times hovering around the 18-19W mark
instead of bouncing anywhere between 18-22W.

		Dave

Re: 2.6.15-ck1

[Philipp Rumpf]

Out of curiosity, why didn't you do the monitoring using
/proc/acpi/battery/.../{state,info} (while running off battery)?  I
think that should have much finer granularity, and avoid various
capacitors that might be in the way and explain the effect you
noticed.

I also tried something that sounds like dynticks a couple of years
back, but found that TCP timers made the really long idle times I was
looking for (my idea was actually to use the RTC to wake up the CPU)
impossible.

prumpf

On 1/4/06, Dave Jones <davej@redhat.com> wrote:
> On Wed, Jan 04, 2006 at 12:00:00PM +1100, Con Kolivas wrote:
>  >  +2.6.15-dynticks-060101.patch
>  >  +dynticks-disable_smp_config.patch
>  > Latest version of the dynticks patch. This is proving stable and effective on
>  > virtually all uniprocessor machines and will benefit systems that desire
>  > power savings. SMP kernels (even on UP machines) still misbehave so this
>  > config option is not available by default for this stable kernel.
>
> I've been curious for some time if this would actually show any measurable
> power savings. So I hooked up my laptop to a gizmo[1] that shows how much
> power is being sucked.
>
> both before, and after, it shows my laptop when idle is pulling 21W.
> So either the savings here are <1W (My device can't measure more accurately
> than a single watt), or this isn't actually buying us anything at all, or
> something needs tuning.
>
>                 Dave
>
> [1] http://www.thinkgeek.com/gadgets/electronic/7657/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: 2.6.15-ck1

[Dave Jones]

On Fri, Jan 13, 2006 at 09:42:26PM -0600, Philipp Rumpf wrote:
 > Out of curiosity, why didn't you do the monitoring using
 > /proc/acpi/battery/.../{state,info} (while running off battery)?  I
 > think that should have much finer granularity, and avoid various
 > capacitors that might be in the way and explain the effect you
 > noticed.

ACPI battery reporting seems hit-or-miss at times.
Sometimes it seems to not update for ages, and then suddenly
there's a burst when suddenly 5% of the battery drains in
seconds.   As an overall 'how much battery is left' thing it seems
ok, but I don't trust it for accurate measurements of power drain.

Whether this is a firmware deficiency causing us not to see
regular interrupts, or a problem with the acpi parser I don't know.

		Dave

Re: [ck] Re: 2.6.15-ck1

[Jens Axboe]

On Fri, Jan 13 2006, Dave Jones wrote:
> On Fri, Jan 13, 2006 at 09:42:26PM -0600, Philipp Rumpf wrote:
>  > Out of curiosity, why didn't you do the monitoring using
>  > /proc/acpi/battery/.../{state,info} (while running off battery)?  I
>  > think that should have much finer granularity, and avoid various
>  > capacitors that might be in the way and explain the effect you
>  > noticed.
> 
> ACPI battery reporting seems hit-or-miss at times.
> Sometimes it seems to not update for ages, and then suddenly
> there's a burst when suddenly 5% of the battery drains in
> seconds.   As an overall 'how much battery is left' thing it seems
> ok, but I don't trust it for accurate measurements of power drain.
> 
> Whether this is a firmware deficiency causing us not to see
> regular interrupts, or a problem with the acpi parser I don't know.

Or could very well be a problem with your battery.

-- 
Jens Axboe

Re: 2.6.15-ck1

[Tomasz Torcz]

On Fri, Jan 13, 2006 at 03:19:29PM -0400, Daniel Petrini wrote:
> Hi Tomasz,
> 
> Just to make sure if there isn't any timer that is not visible in the
> screen (unlikely but...). Can you run timertop with background
> acquisition:
> 
> timertop -t 100
> 
> And analyse the output to verify if there isn't timers with that frequency?

  Nothing suspicious:


Timer Top v 0.9.8
No.   PID         Command      Count         Function       Address 
  1  4072   multiload-apple        3        process_timeout c0121e08
  2  3602                 X       17             it_real_fn c011deff
  3  3985            python       45        process_timeout c0121e08
  4  4492        postmaster        7        process_timeout c0121e08
  5  3931          nautilus        1        process_timeout c0121e08
  6  4074              mono        9        process_timeout c0121e08
  7  4059     mixer_applet2        7        process_timeout c0121e08
  8  4713             mrxvt        3        process_timeout c0121e08
  9     0                 -        4       i8042_timer_func c0230f2b
 10     1              mono        1       watermark_wakeup c013f6f5
 11    18              mono        3               (module) e2a3409b
 12  4122              mono        2        process_timeout c0121e08
 13     0                 -        1               (module) e2bc2381
 14     0                 -        1            wb_timer_fn c013acc0
 15     0                 -        3  delayed_work_timer_fn c0126a96
 16     0                 -        1     blk_unplug_timeout c01ccc1b
 17     0                 -        1               (module) d0697f40
 18     3        watchdog/0        1        process_timeout c0121e08
 19  4067   netspeed_applet        1        process_timeout c0121e08
 20  4069    cpufreq-applet        1        process_timeout c0121e08
 21  3796   gnome-screensav        1        process_timeout c0121e08
 22  4540             httpd        1        process_timeout c0121e08
 23  3512              ntpd        1             it_real_fn c011deff
 24 17603          timertop        1        process_timeout c0121e08

-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
zdzichu@irc.-nie.spam-.pl    wagon filled with backup tapes." -- Jim Gray

Re: 2.6.15-ck1

[Ben Slusky]

On Thu, 12 Jan 2006 18:03:15 -0500, Dave Jones wrote:
> As soon as that usb timer hits (every 250ms iirc) you'll bounce back out
> of any low-power state you may be in. It's a bit craptastic that we do
> this, even if we don't have any USB devices plugged in.

Is your USB controller an OHCI? If so, try reverting this patch:
<URL:http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110313153001002&w=2>

Apparently some mfrs' OHCI controllers need this patch to function sanely,
but mine (in a Libretto L5) won't suspend after this change, and works
great without it.

HTH,
-
-Ben


-- 
Ben Slusky                      | The only "intuitive" inter-
sluskyb@paranoiacs.org          | face is the nipple. After
sluskyb@stwing.org              | that, it's all learned.
PGP keyID ADA44B3B              |               -Bruce Ediger