process wakeups

[Lennart Poettering]

On Mon, 14.07.08 14:57, Ulrich Drepper (drepper at 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