On Mon, 14.07.08 14:57, Ulrich Drepper (drepper(a)redhat.com) wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One of the worst problems wrt energy savings we have today are all the
wakeups processes request. This is not just an issue for laptops, it
relevant everywhere.
To see the size of the problem run the attached systemtap script. On my
laptop I see the following output (47 secs runtime):
uid | poll select epoll itimer futex nanosle signal| process
29799 |15941 7971 0 0 0 0 0| npviewer.bin
29841 | 253 0 0 0 1531 0 0| thunderbird-bin
3017 | 447 0 0 0 0 0 0| pulseaudio
I would assume that this is just a followup by Flash/npviewer. Flash
opens an audio stream and never closes it again during its entire
runtime. While the audio stream is open. PA also needs to keep the
audio device open. As long as the audio device is open we we will
schedule audio via timers. The PA version from rawhide should
not generate any wakeups when completely idle (i.e. no streams
allocated or all streams that are allocated are properly paused)
But of course, I might be mistaken, I didn't run this test, and
pointing fingers to other people's software (flash) might just by an
automatic reflex of me. Last time I checked PA didn't show up in
powertop when idle, to say the least. I'll check again.
2467 | 76 0 0 0 0 0 0| hald
2471 | 8 0 0 0 0 0 0| hald-runner
2620 | 58 0 0 0 0 0 0| NetworkManager
13174 | 214 0 0 0 0 0 0| stapio
3044 | 48 0 0 0 0 0 0| gnome-panel
9115 | 16 0 0 0 0 0 0| nm-vpnc-service
3112 | 32 0 0 0 0 0 0| gpk-update-icon
3108 | 24 0 0 0 0 0 0| nm-applet
3052 | 274 0 0 1 0 0 0| gnome-terminal
3115 | 29 0 0 0 0 0 0| gnome-power-man
3055 | 16 0 0 0 0 0 0| bluetooth-apple
3093 | 16 0 0 0 0 0 0| krb5-auth-dialo
2633 | 16 0 0 0 0 0 0| gdm-binary
2724 | 16 0 0 0 0 0 0| gdm-simple-slav
2630 | 16 0 0 0 0 0 0| nm-system-setti
2470 | 16 0 0 0 0 0 0| console-kit-dae
2385 | 16 0 0 0 0 0 0| avahi-daemon
For avahi-daemon the wakeups are highly dependant on how much traffic
actually goes on on the network and how long Avahi has already been
running. I think the room for improvements here is rather minimal, I
would assume, due to the way the protocol works: in mDNS traffic is
scheduled based on time. Basically, every packet we send is implicitly
delayed to increase the chance that we can merge multiple messages
into a single packet.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4