Hi,
On Thu, Nov 01, 2007 at 07:39:08PM +0100, Andreas Mohr wrote:
> I just tried powertop on stock 2.6.23 on this box now and noticed that
> neigh_periodic_timer has these 17.7 wakeups/sec there, too.
Completely changed hardware (now on AMD 690G with X2, currently 2.6.25-rc7),
powertop output is now much worse here, relatively spoken:
P-states (frequencies)
2,00 Ghz 0,0%
1,80 Ghz 0,0%
1000 Mhz 100,0%
< Detailed C-state information is only available on Mobile CPUs (laptops) >
Wakeups-from-idle per second : 62,7 interval: 10,0s
no ACPI power usage estimate available
Top causes for wakeups:
54,9% ( 37,5) <kernel core> : neigh_table_init_no_netlink
(neigh_periodic_ti
10,8% ( 7,4) artsd : schedule_timeout (process_timeout)
10,2% ( 7,0) <interrupt> : ahci, firewire_ohci
5,6% ( 3,8) kicker : schedule_timeout (process_timeout)
1,8% ( 1,2) kdesktop : schedule_timeout (process_timeout)
1,8% ( 1,2) Xorg : do_setitimer (it_real_fn)
1,5% ( 1,0) cpupw : do_nanosleep (hrtimer_wakeup)
1,5% ( 1,0) kwrapper : do_nanosleep (hrtimer_wakeup)
1,5% ( 1,0) artsd : do_setitimer (it_real_fn)
1,5% ( 1,0) kwin : schedule_timeout (process_timeout)
0,7% ( 0,5) <interrupt> : eth0
0,7% ( 0,5) ifconfig : __netdev_watchdog_up (dev_watchdog)
0,7% ( 0,5) schedtoold : do_nanosleep (hrtimer_wakeup)
0,7% ( 0,5) linpopup : schedule_timeout (process_timeout)
Without neigh_table_init_no_netlink() interference,
the system's timer behaviour would now be truly glacial thanks to
generally improved wakeup behaviour. As it stands, we now even have a
doubled wakeup rate (37.5 vs. 17.7) for this handling,
possibly due to dual-core????
I've seen that on very rare occasions there's an additional neigh-related
powertop entry visible, caused by lisa (KDE networking).
Possibly lisa's configuration is initially triggering the high activity
of neigh table code somehow, I should check this.
One thing I'm still puzzled about is why this extremely high activity
does not occur on many other systems (internet powertop dumps),
yet on mine it does.
I'm currently still(?) running on HZ=300, and this probably has
to do with it (need to check it).
On the more technical follow-up discussion titled "Grave neigh_periodic_timer
bug?" (which I almost couldn't locate any more somehow) I suggested
the handling to be buggy, however it seems that the base_reachable_time
reference value itself was already (semi-?)appropriately scaled
by the /proc item handler itself.
However I'm still rather sure that something _must_ be somewhat fishy
with the entry scanning interval calculation.
I'll do a HZ=100 test run now and possibly further code investigation
as time permits, however one thing is obvious: compared to other
timer system activity this one is very visible and should be tackled
one way or another.
Thanks,
Andreas Mohr
_______________________________________________
Power mailing list
[email protected]
http://www.bughost.org/mailman/listinfo/power
