Dear all,
(please CC)
it seems that some of the (?)recent(?) changes have increased the
power consumption of my note book considerably.
First of all, running powertop with normal programs started, but
doing nothing, I am still at 14W while I could go down to 9W before
(but the 9W was with dimmed display).
In the list of top causes for wakeup I have
Top causes for wakeups:
34.2% (185.3) [kernel scheduler] Load balancing tick
23.9% (129.6) [extra timer interrupt]
10.8% ( 58.6) firefox-bin
9.2% ( 49.7) [iwlagn] <interrupt>
7.2% ( 39.1) [kernel core] hrtimer_start (tick_sched_timer)
3.9% ( 20.9) PS/2 keyboard/mouse/touchpad interrupt
which show one new thing to me I haven't seen before, the Loa balancing tick.
Furthermore, I also had the feeling that while being suspend to RAM
the battery is also emptied faster then before, but by now I have not
concise data points for that.
I am running the latest kernel pulled from git.kernel.org, linux-2.6.
I have seen some patches from Venkatesh Pallipadi dealing twith this
issue (http://lkml.org/lkml/2010/6/9/109) but it does not apply to
the current kernel sources at all.
Please let me know if you have any suggestions of if I should test
something.
Thanks and all the best
Norbert
Please CC
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
HARBOTTLE (n.)
A particular kind of fly which lives inside double glazing.
--- Douglas Adams, The Meaning of Liff
On Wed, 2010-07-07 at 01:45 +0900, Norbert Preining wrote:
> it seems that some of the (?)recent(?) changes have increased the
> power consumption of my note book considerably.
>
> First of all, running powertop with normal programs started, but
> doing nothing, I am still at 14W while I could go down to 9W before
> (but the 9W was with dimmed display).
>
> In the list of top causes for wakeup I have
> Top causes for wakeups:
> 34.2% (185.3) [kernel scheduler] Load balancing tick
> 23.9% (129.6) [extra timer interrupt]
> 10.8% ( 58.6) firefox-bin
> 9.2% ( 49.7) [iwlagn] <interrupt>
> 7.2% ( 39.1) [kernel core] hrtimer_start (tick_sched_timer)
> 3.9% ( 20.9) PS/2 keyboard/mouse/touchpad interrupt
> which show one new thing to me I haven't seen before, the Loa balancing tick.
I think that is what powertop calls our regular tick (Arjan?), and as
long as you're not idle nohz can't kick in, I'd be looking at what keeps
nohz from happening,.. those extra timer interrupts could be
responsible..
> Furthermore, I also had the feeling that while being suspend to RAM
> the battery is also emptied faster then before, but by now I have not
> concise data points for that.
>
> I am running the latest kernel pulled from git.kernel.org, linux-2.6.
Right, I'm quite puzzled by that, looking through the result of:
git log v2.6.34..origin/master kernel/sched*
Nothing really shouts me, me, me :-)
You could try and look at:
99bd5e2f245d8 (sched: Fix select_idle_sibling() logic in select_task_rq_fair())
3c93717cfa513 (sched: Fix over-scheduling bug)
And that latter only if you actually have group scheduling enabled.
Other than that, I'm afraid I'll have to ask you to bisect this.
> I have seen some patches from Venkatesh Pallipadi dealing twith this
> issue (http://lkml.org/lkml/2010/6/9/109) but it does not apply to
> the current kernel sources at all.
Those patches are merged and waiting for the .36 merge window, try a
-tip kernel
(git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git) if
you want to give them a go.
On Thu, 08 Jul 2010 11:06:32 +0200
Peter Zijlstra <[email protected]> wrote:
> On Wed, 2010-07-07 at 01:45 +0900, Norbert Preining wrote:
>
> > it seems that some of the (?)recent(?) changes have increased the
> > power consumption of my note book considerably.
> >
> > First of all, running powertop with normal programs started, but
> > doing nothing, I am still at 14W while I could go down to 9W before
> > (but the 9W was with dimmed display).
> >
> > In the list of top causes for wakeup I have
> > Top causes for wakeups:
> > 34.2% (185.3) [kernel scheduler] Load balancing tick
> > 23.9% (129.6) [extra timer interrupt]
> > 10.8% ( 58.6) firefox-bin
> > 9.2% ( 49.7) [iwlagn] <interrupt>
> > 7.2% ( 39.1) [kernel core] hrtimer_start (tick_sched_timer)
> > 3.9% ( 20.9) PS/2 keyboard/mouse/touchpad interrupt
> > which show one new thing to me I haven't seen before, the Loa
> > balancing tick.
>
> I think that is what powertop calls our regular tick (Arjan?), and as
it's "hrtimer_start_range_ns (tick_sched_timer)" if it's done by the
idle thread.
On Thu, 2010-07-08 at 04:57 -0700, Arjan van de Ven wrote:
> On Thu, 08 Jul 2010 11:06:32 +0200
> Peter Zijlstra <[email protected]> wrote:
>
> > On Wed, 2010-07-07 at 01:45 +0900, Norbert Preining wrote:
> >
> > > it seems that some of the (?)recent(?) changes have increased the
> > > power consumption of my note book considerably.
> > >
> > > First of all, running powertop with normal programs started, but
> > > doing nothing, I am still at 14W while I could go down to 9W before
> > > (but the 9W was with dimmed display).
> > >
> > > In the list of top causes for wakeup I have
> > > Top causes for wakeups:
> > > 34.2% (185.3) [kernel scheduler] Load balancing tick
> > > 23.9% (129.6) [extra timer interrupt]
> > > 10.8% ( 58.6) firefox-bin
> > > 9.2% ( 49.7) [iwlagn] <interrupt>
> > > 7.2% ( 39.1) [kernel core] hrtimer_start (tick_sched_timer)
> > > 3.9% ( 20.9) PS/2 keyboard/mouse/touchpad interrupt
> > > which show one new thing to me I haven't seen before, the Loa
> > > balancing tick.
> >
> > I think that is what powertop calls our regular tick (Arjan?), and as
>
> it's "hrtimer_start_range_ns (tick_sched_timer)" if it's done by the
> idle thread.
>
then wth is "[kernel scheduler] load balancing tick"?
and for that matter, what is "[extra timer interrupt]", surely the timer
hardware doesn't generate spurious interrupts?
On Do, 08 Jul 2010, Peter Zijlstra wrote:
> then wth is "[kernel scheduler] load balancing tick"?
> and for that matter, what is "[extra timer interrupt]", surely the timer
> hardware doesn't generate spurious interrupts?
Just one more point, searching a bit more in the net I found the following
patch (forgot who wrote it) which I merged into my current git:
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index a878b53..f26efba 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -3248,6 +3248,9 @@ int select_nohz_load_balancer(int stop_tick)
if (stop_tick) {
cpu_rq(cpu)->in_nohz_recently = 1;
+ if (!mc_capable())
+ return 0;
+
if (!cpu_active(cpu)) {
if (atomic_read(&nohz.load_balancer) != cpu)
return 0;
@@ -3297,6 +3300,9 @@ int select_nohz_load_balancer(int stop_tick)
if (!cpumask_test_cpu(cpu, nohz.cpu_mask))
return 0;
+ if (!mc_capable())
+ return 0;
+
cpumask_clear_cpu(cpu, nohz.cpu_mask);
if (atomic_read(&nohz.load_balancer) == cpu)
Now the output looks like:
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 2.7%) Turbo Mode 0.2%
C0 0.0ms ( 0.0%) 2.54 Ghz 0.0%
C1 mwait 0.8ms ( 0.0%) 1.60 Ghz 0.0%
C2 mwait 0.4ms ( 1.4%) 800 Mhz 99.8%
C6 mwait 4.9ms (95.9%)
Wakeups-from-idle per second : 228.4 interval: 10.0s
Power usage (ACPI estimate): 11.7W (7.3 hours)
Top causes for wakeups:
22.4% ( 55.4) [kernel scheduler] Load balancing tick
16.6% ( 41.2) [iwlagn] <interrupt>
16.0% ( 39.7) [extra timer interrupt]
15.2% ( 37.7) [kernel core] hrtimer_start (tick_sched_timer)
13.7% ( 33.9) firefox-bin
2.4% ( 5.9) [ahci] <interrupt>
2.0% ( 5.0) syndaemon
which looks better
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
OSWALDTWISTLE (n. Old Norse)
Small brass wind instrument used for summoning Vikings to lunch when
they're off on their longships, playing.
--- Douglas Adams, The Meaning of Liff
On Thu, 2010-07-08 at 21:04 +0900, Norbert Preining wrote:
> Just one more point, searching a bit more in the net I found the following
> patch (forgot who wrote it) which I merged into my current git:
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index a878b53..f26efba 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -3248,6 +3248,9 @@ int select_nohz_load_balancer(int stop_tick)
> if (stop_tick) {
> cpu_rq(cpu)->in_nohz_recently = 1;
>
> + if (!mc_capable())
> + return 0;
> +
> if (!cpu_active(cpu)) {
> if (atomic_read(&nohz.load_balancer) != cpu)
> return 0;
> @@ -3297,6 +3300,9 @@ int select_nohz_load_balancer(int stop_tick)
> if (!cpumask_test_cpu(cpu, nohz.cpu_mask))
> return 0;
>
> + if (!mc_capable())
> + return 0;
> +
> cpumask_clear_cpu(cpu, nohz.cpu_mask);
>
> if (atomic_read(&nohz.load_balancer) == cpu)
Right, so that is a buggy patch, see the original discussion:
http://lkml.org/lkml/2010/4/26/249
> which looks better
The thing is, we didn't change that code recently, the patches that are
supposed to cure the nohz balancer are still pending (in -tip and
-next).
That said, we did frob something with the whole nohz thing, does the
below cure anything:
---
kernel/time/tick-sched.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 813993b..9bc8029 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -325,7 +325,7 @@ void tick_nohz_stop_sched_tick(int inidle)
} while (read_seqretry(&xtime_lock, seq));
if (rcu_needs_cpu(cpu) || printk_needs_cpu(cpu) ||
- arch_needs_cpu(cpu) || nohz_ratelimit(cpu)) {
+ arch_needs_cpu(cpu) /* || nohz_ratelimit(cpu) */) {
next_jiffies = last_jiffies + 1;
delta_jiffies = 1;
} else {
On Do, 08 Jul 2010, Peter Zijlstra wrote:
> Right, so that is a buggy patch, see the original discussion:
> http://lkml.org/lkml/2010/4/26/249
Well, to me it wasn't so clear that this was buggy *for*my*system*
(core2)
> That said, we did frob something with the whole nohz thing, does the
> below cure anything:
Looks promising, reverting the old patch, adding that one, building,
running, unplugging ppower, powertop runs now since some time,
it seems that we are back to better situation:
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 1.5%) Turbo Mode 0.0%
C0 0.0ms ( 0.0%) 2.54 Ghz 0.0%
C1 mwait 0.0ms ( 0.0%) 1.60 Ghz 0.0%
C2 mwait 0.3ms ( 0.9%) 800 Mhz 100.0%
C6 mwait 8.5ms (97.6%)
Wakeups-from-idle per second : 139.9 interval: 15.0s
Power usage (ACPI estimate): 10.0W (8.8 hours) (long term: 1.7W,/50.9h)
Top causes for wakeups:
32.2% ( 46.1) [kernel scheduler] Load balancing tick
20.4% ( 29.1) [iwlagn] <interrupt>
12.6% ( 18.0) [extra timer interrupt]
6.5% ( 9.3) [ahci] <interrupt>
3.7% ( 5.3) [kernel core] hrtimer_start (tick_sched_timer)
3.5% ( 5.0) syndaemon
3.4% ( 4.8) [acpi] <interrupt>
2.3% ( 3.3) yarssr
Power is going down to below 10W with brightness dimmed.
Thanks.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
I'm going to have a look.'
He glanced round at the others.
`Is no one going to say, "No you can't possibly, let me go
instead"?'
They all shook their heads.
`Oh well.'
--- Ford attempting to be heroic whilst being seiged by
--- Shooty and Bangbang.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
On Thu, 2010-07-08 at 21:46 +0900, Norbert Preining wrote:
> Looks promising, reverting the old patch, adding that one, building,
> running, unplugging ppower, powertop runs now since some time,
> it seems that we are back to better situation:
Hrmm, Mike seems you wrecked power usage..
So nohz_ratelimit() prevents us from entering NOHZ when the last attempt
was less than 1/2 a jiffy ago (fwiw: NSEC_PER_SEC/HZ == TICK_NSEC).
Its either entering idle or irq_exit trying to enter nohz state, if we
keep skipping it it means that we get enough interrupt activity to
render nohz useless anyway.. so not quite sure how this wrecks things..
> and for that matter, what is "[extra timer interrupt]", surely the
> timer hardware doesn't generate spurious interrupts?
extra timer interrupt are those cases where we see the hardware
interrupt fire, but we do not have software timers to account for them.
two cases this can happen
* a NO_HZ bug
* we are idle longer than the longest interval we can program the hw
timer for. Without HPET this can happen.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Thu, 2010-07-08 at 15:23 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 21:46 +0900, Norbert Preining wrote:
> > Looks promising, reverting the old patch, adding that one, building,
> > running, unplugging ppower, powertop runs now since some time,
> > it seems that we are back to better situation:
>
> Hrmm, Mike seems you wrecked power usage..
>
> So nohz_ratelimit() prevents us from entering NOHZ when the last attempt
> was less than 1/2 a jiffy ago (fwiw: NSEC_PER_SEC/HZ == TICK_NSEC).
>
> Its either entering idle or irq_exit trying to enter nohz state, if we
> keep skipping it it means that we get enough interrupt activity to
> render nohz useless anyway.. so not quite sure how this wrecks things..
OK, so Arjan said the gain could come from tricking the idle governor
into not using deeper C states. He also said he significantly cured said
governor in .35.
Mike could you re-run your netperf tests that showed the 10% throughput
gain? Hopefully the fixed governor will yield the same result and we can
kill off this ratelimit thing.
On Thu, 2010-07-08 at 17:59 +0200, Peter Zijlstra wrote:
> OK, so Arjan said the gain could come from tricking the idle governor
> into not using deeper C states. He also said he significantly cured said
> governor in .35.
>
> Mike could you re-run your netperf tests that showed the 10% throughput
> gain? Hopefully the fixed governor will yield the same result and we can
> kill off this ratelimit thing.
FWIW, on my test-box, 35-rc4-tip, using ondemand:
with nohz_ratelimit() : ~2119.54 MB/s
without nohz_ratelimit() : ~2353.03 MB/s
Seems to suggest we should simply kill the thing..
On Thu, 2010-07-08 at 15:23 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 21:46 +0900, Norbert Preining wrote:
> > Looks promising, reverting the old patch, adding that one, building,
> > running, unplugging ppower, powertop runs now since some time,
> > it seems that we are back to better situation:
>
> Hrmm, Mike seems you wrecked power usage..
>
> So nohz_ratelimit() prevents us from entering NOHZ when the last attempt
> was less than 1/2 a jiffy ago (fwiw: NSEC_PER_SEC/HZ == TICK_NSEC).
>
> Its either entering idle or irq_exit trying to enter nohz state, if we
> keep skipping it it means that we get enough interrupt activity to
> render nohz useless anyway.. so not quite sure how this wrecks things.
You can't win at this game.
I really don't like giving up anything, but thinking about it, if I were
the maintainer, I'd just revert the damn thing as being more trouble
than it's worth.
It makes a large difference at the extreme end of the spectrum when
scheduling cross cpu (which we now actively try to do to maximize ramp
throughput), but ever less as frequency diminishes. I've yet to see a
load I can respect at close to max ctx frequency, where optimization
earns it's beans and biscuits.
Ego: If thine eye offends thee, pluck it out.
-Mike
On Thu, 2010-07-08 at 17:59 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 15:23 +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-08 at 21:46 +0900, Norbert Preining wrote:
> > > Looks promising, reverting the old patch, adding that one, building,
> > > running, unplugging ppower, powertop runs now since some time,
> > > it seems that we are back to better situation:
> >
> > Hrmm, Mike seems you wrecked power usage..
> >
> > So nohz_ratelimit() prevents us from entering NOHZ when the last attempt
> > was less than 1/2 a jiffy ago (fwiw: NSEC_PER_SEC/HZ == TICK_NSEC).
> >
> > Its either entering idle or irq_exit trying to enter nohz state, if we
> > keep skipping it it means that we get enough interrupt activity to
> > render nohz useless anyway.. so not quite sure how this wrecks things..
>
> OK, so Arjan said the gain could come from tricking the idle governor
> into not using deeper C states. He also said he significantly cured said
> governor in .35.
>
> Mike could you re-run your netperf tests that showed the 10% throughput
> gain? Hopefully the fixed governor will yield the same result and we can
> kill off this ratelimit thing.
The gain is (well was last time I checked), but as noted, I'd just call
it a misguided optimization and be done with it.
-Mike
On Thu, 2010-07-08 at 21:40 +0200, Mike Galbraith wrote:
> > Mike could you re-run your netperf tests that showed the 10% throughput
> > gain? Hopefully the fixed governor will yield the same result and we can
> > kill off this ratelimit thing.
>
> The gain is (well was last time I checked), but as noted, I'd just call
> it a misguided optimization and be done with it.
It would still be good to know what your machine does, if you can still
see a difference there might still be something to look at.
On Thu, 08 Jul 2010 22:44:14 +0200
Peter Zijlstra <[email protected]> wrote:
> On Thu, 2010-07-08 at 21:40 +0200, Mike Galbraith wrote:
> > > Mike could you re-run your netperf tests that showed the 10%
> > > throughput gain? Hopefully the fixed governor will yield the same
> > > result and we can kill off this ratelimit thing.
> >
> > The gain is (well was last time I checked), but as noted, I'd just
> > call it a misguided optimization and be done with it.
>
> It would still be good to know what your machine does, if you can
> still see a difference there might still be something to look at.
>
yeah and if you give me a reason / workload to improve the idle
governor even more.....
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Thu, 2010-07-08 at 22:44 +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 21:40 +0200, Mike Galbraith wrote:
> > > Mike could you re-run your netperf tests that showed the 10% throughput
> > > gain? Hopefully the fixed governor will yield the same result and we can
> > > kill off this ratelimit thing.
> >
> > The gain is (well was last time I checked), but as noted, I'd just call
> > it a misguided optimization and be done with it.
>
> It would still be good to know what your machine does, if you can still
> see a difference there might still be something to look at.
git .today.
marge:..git/linux-2.6 # netperf.sh 30
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 30.00 102272.73
16384 87380
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET : cpu bind
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 30.00 97638.99
16384 87380
turns ratelimiting off
marge:..git/linux-2.6 # netperf.sh 30
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 30.00 92991.02
16384 87380
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET : cpu bind
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 30.00 97665.27
16384 87380
btw, if you don't set governor to performance, you can get crud
throughput like below, because the ondemand governor doesn't necessarily
notice that the CPUs really are busy when waking cross-cpu.
marge:..git/linux-2.6 # netperf.sh 10
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 73341.95 <== blech
16384 87380
TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 127.0.0.1 (127.0.0.1) port 0 AF_INET : cpu bind
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 97695.45
16384 87380
On Thu 2010-07-08 11:06:32, Peter Zijlstra wrote:
> On Wed, 2010-07-07 at 01:45 +0900, Norbert Preining wrote:
>
> > it seems that some of the (?)recent(?) changes have increased the
> > power consumption of my note book considerably.
> >
> > First of all, running powertop with normal programs started, but
> > doing nothing, I am still at 14W while I could go down to 9W before
> > (but the 9W was with dimmed display).
> >
> > In the list of top causes for wakeup I have
> > Top causes for wakeups:
> > 34.2% (185.3) [kernel scheduler] Load balancing tick
> > 23.9% (129.6) [extra timer interrupt]
> > 10.8% ( 58.6) firefox-bin
> > 9.2% ( 49.7) [iwlagn] <interrupt>
> > 7.2% ( 39.1) [kernel core] hrtimer_start (tick_sched_timer)
> > 3.9% ( 20.9) PS/2 keyboard/mouse/touchpad interrupt
> > which show one new thing to me I haven't seen before, the Loa balancing tick.
>
14W vs 9W is very significant -- is some DMA keeping system from
entering C3? rmmod usb?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html