Hi Arjan,
I have been using powertop to find wakeup events and try to correlate
with total interrupts received by the idle system. I want to see the
rate of local timer interrupts go down as we optimise the drivers and
user-space applications to avoid polling.
I observed that powertop shows very low wake-from-idle rate on SMP
system and the wake-from-idle rate is very high when all other CPUs are
offlined and only CPU0 is operational. I have routed all irqs to CPUs
before the experiment.
Can you please help me understand how exactly the wake-from-idle rate
is computed?
Experiment:
-----------
Completely idle system (2 socket dual core), no usb, most daemons
turned off.
[EMAIL PROTECTED] sv]# powertop -d
PowerTOP 1.9 (C) 2007 Intel Corporation
Collecting data for 15 seconds
< Detailed C-state information is only available on Mobile CPUs (laptops) >
P-states (frequencies)
2.40 Ghz 0.0%
2.13 Ghz 0.0%
1.87 Ghz 0.0%
1.60 Ghz 100.0%
Wakeups-from-idle per second : 4.2 interval: 15.0s
no ACPI power usage estimate available
Top causes for wakeups:
60.6% ( 5.1) <interrupt> : eth0
11.8% ( 1.0) ip : bnx2_open (bnx2_timer)
5.5% ( 0.5) <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_timer)
2.4% ( 0.2) <interrupt> : aacraid
2.4% ( 0.2) <kernel IPI> : function call interrupts
2.4% ( 0.2) init : schedule_timeout (process_timeout)
2.4% ( 0.2) python : schedule_timeout (process_timeout)
2.4% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog)
2.4% ( 0.2) sendmail : schedule_timeout (process_timeout)
2.4% ( 0.2) <kernel core> : page_writeback_init (wb_timer_fn)
0.8% ( 0.1) <kernel core> : sk_reset_timer (tcp_delack_timer)
0.8% ( 0.1) sshd : sk_reset_timer (tcp_write_timer)
0.8% ( 0.1) rc.sysinit : start_this_handle (commit_timeout)
0.8% ( 0.1) <kernel core> : init_nonfatal_mce_checker
(delayed_work_timer_fn)
0.8% ( 0.1) <kernel core> : ip_rt_init (delayed_work_timer_fn)
0.8% ( 0.1) <kernel core> : neigh_add_timer (neigh_timer_handler)
0.8% ( 0.1) syslogd : do_setitimer (it_real_fn)
[EMAIL PROTECTED] sv]# cat /proc/interrupts |grep LOC;sleep 15; cat
/proc/interrupts |grep LOC
LOC: 304865 11927 5541 9878 Local timer interrupts
LOC: 304953 11952 5556 9915 Local timer interrupts
------ ----- ---- ----
88 + 25 + 15 + 37 = 165
[EMAIL PROTECTED] sv]# for i in 1 2 3; do echo 0 >
/sys/devices/system/cpu/cpu$i/online; done
[EMAIL PROTECTED] sv]# cat /proc/interrupts |grep LOC;sleep 15; cat
/proc/interrupts |grep LOC
LOC: 305585 Local timer interrupts
LOC: 305671 Local timer interrupts
-------
86
[EMAIL PROTECTED] sv]# powertop -d
PowerTOP 1.9 (C) 2007 Intel Corporation
Collecting data for 15 seconds
< Detailed C-state information is only available on Mobile CPUs (laptops) >
P-states (frequencies)
2.40 Ghz 0.0%
2.13 Ghz 0.0%
1.87 Ghz 0.0%
1.60 Ghz 100.0%
Wakeups-from-idle per second : 14.5 interval: 15.0s
no ACPI power usage estimate available
Top causes for wakeups:
56.0% ( 3.7) <interrupt> : eth0
15.0% ( 1.0) ip : bnx2_open (bnx2_timer)
7.0% ( 0.5) <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_timer)
3.0% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog)
3.0% ( 0.2) sendmail : schedule_timeout (process_timeout)
3.0% ( 0.2) <kernel core> : page_writeback_init (wb_timer_fn)
3.0% ( 0.2) init : schedule_timeout (process_timeout)
3.0% ( 0.2) python : schedule_timeout (process_timeout)
2.0% ( 0.1) <interrupt> : aacraid
1.0% ( 0.1) <kernel core> : sk_reset_timer (tcp_delack_timer)
1.0% ( 0.1) sshd : sk_reset_timer (tcp_write_timer)
1.0% ( 0.1) <kernel core> : neigh_add_timer (neigh_timer_handler)
1.0% ( 0.1) rc.sysinit : start_this_handle (commit_timeout)
1.0% ( 0.1) <kernel core> : init_nonfatal_mce_checker
(delayed_work_timer_fn)
When I offlined the 3 CPUs and make the machine uni-processor, thereby
migrating all timers and tasks to cpu0, I see a increase in wakeup
rate while I expect a decrease. When 4 idle CPUs were available, the
probability of wake from idle is much higher than in the case of
single CPU configuration.
Thanks,
Vaidy
_______________________________________________
Discuss mailing list
[email protected]
http://mail.lesswatts.org/mailman/listinfo/discuss
