Hi,
testing powertop (timer wakeup tracing) on my mother's 2.6.22-ck1 system,
I found the following "fully idle" output:
Wakeups-from-idle per second : 220,6
no ACPI power usage estimate available
Top causes for wakeups:
38,9% ( 60,1) <interrupt> : ohci_hcd:usb2, [EMAIL
PROTECTED]:0000:01:00.0
13,2% ( 20,4) knotify : schedule_timeout (process_timeout)
11,5% ( 17,7) <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_timer)
10,4% ( 16,0) <interrupt> : ide1
7,8% ( 12,0) kicker : schedule_timeout (process_timeout)
7,1% ( 11,0) Xorg : do_setitimer (it_real_fn)
4,3% ( 6,6) artsd : schedule_timeout (process_timeout)
1,3% ( 2,0) <kernel core> : clocksource_register
(clocksource_watchdog)
0,6% ( 1,0) artsd : do_setitimer (it_real_fn)
0,6% ( 1,0) kwrapper : do_nanosleep (hrtimer_wakeup)
0,4% ( 0,6) <interrupt> : eth0
Everything here is pretty much ok, except for the neigh_periodic_timer
thing, which is sharply increased when compared to all usual internet reports
concerning powertop neigh_periodic_timer. Those reports *always* have it at
0.2 wakeups / second, whereas for me it's *always* almost factor 100 -
17.7 wakeups / second.
config is AMD Duron (modded to mobile CPU)
2.6.22-ck1 with HZ=300, dynticks, highres timers,
voluntary kernel preemption (desktop), normal IPv4 setup
with 3c905B card (3c59x) (BNC connection, though!!).
I'm not quite sure what this neighbour table stuff is about and how to
diagnose it, thus only a small
# ip -statistics neigh show
192.168.168.10 dev eth0 lladdr 00:a0:c9:0d:92:3f ref 2 used 0/0/0
REACHABLE
and
# rtstat
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_marti|in_marti|
out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
| | tot| mc| ute| | an_dst| an_src|
| _tot| _mc| | ed| miss| verflow| _search|t_search|
6| 14955| 139| 0| 0| 9| 0| 0|
2185| 1392| 23| 0| 0| 0| 0| 27| 38|
and
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:01:02:F1:73:DF
inet addr:192.168.168.2 Bcast:192.168.168.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28190 errors:0 dropped:0 overruns:0 frame:0
TX packets:29471 errors:0 dropped:0 overruns:0 carrier:0
collisions:108 txqueuelen:1000
RX bytes:8165206 (7.7 MiB) TX bytes:3357919 (3.2 MiB)
Interrupt:3 Base address:0xef80
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1301 errors:0 dropped:0 overruns:0 frame:0
TX packets:1301 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:73550 (71.8 KiB) TX bytes:73550 (71.8 KiB)
for now.
I want to stress that this is a small desktop-only system without any complex
routing setup,
thus 20 wakeups / seconds seems extreme overkill / bug.
Thus it seems that
neigh_periodic_timer():
/* Cycle through all hash buckets every base_reachable_time/2 ticks.
* ARP entry timeouts range from 1/2 base_reachable_time to 3/2
* base_reachable_time.
*/
expire = tbl->parms.base_reachable_time >> 1;
expire /= (tbl->hash_mask + 1);
if (!expire)
expire = 1;
if (expire>HZ)
mod_timer(&tbl->gc_timer, round_jiffies(now + expire));
else
mod_timer(&tbl->gc_timer, now + expire);
is problematic somehow, at least in my case.
Any ideas?
And how to provide further relevant debug output?
Thanks,
Andreas Mohr
_______________________________________________
Power mailing list
[email protected]
http://www.bughost.org/mailman/listinfo/power
