On Mon, 14.07.08 14:57, Ulrich Drepper (drepper@xxxxxxxxxx) 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
