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
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/
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
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.
On Wed, 4 Jan 2006 14:05:54 -0500, Dave Jones <[email protected]> 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.
On Thu, Jan 05, 2006 at 07:38:29AM +1100, Grant Coady wrote:
> On Wed, 4 Jan 2006 14:05:54 -0500, Dave Jones <[email protected]> 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
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
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
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
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
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)
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
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
Arjan van de Ven <[email protected]> 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
On Thu, 5 Jan 2006 12:22 pm, Andi Kleen wrote:
> Arjan van de Ven <[email protected]> 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
* Arjan van de Ven <[email protected]> [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
* Con Kolivas <[email protected]> [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
On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote:
> Arjan van de Ven <[email protected]> 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
On Thu, Jan 05, 2006 at 02:22:37AM +0100, Andi Kleen wrote:
> Arjan van de Ven <[email protected]> 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
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 <[email protected]> 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
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
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
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
On 1/5/06, Andi Kleen <[email protected]> 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
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,
[email protected] it's a dangerous thing for a man. -- Alia
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
On 1/4/06, Con Kolivas <[email protected]> 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
[email protected]
http://thesaq.com/
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
On 1/5/06, Kevin Radloff <[email protected]> wrote:
> On 1/4/06, Con Kolivas <[email protected]> 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
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
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
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
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
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?"
[email protected] "God is more forgiving."
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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
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
[email protected] wagon filled with backup tapes." -- Jim Gray
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-
[email protected] | face is the nipple. After
[email protected] | that, it's all learned.
PGP keyID ADA44B3B | -Bruce Ediger