Re: process wakeups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2008-07-14 at 14:57 -0700, Ulrich Drepper 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
>  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

While there are probably stupidities in NM, there are also known
externally-driven wakeup causes including:

1) until 2.6.27 lands, there's no way to get the rfkill switch
state-change events, so NM polls them every 6 seconds _iff_ they exist.
Unfortunately, they often exist in HAL even though there are no physical
switches on the laptop because the nice rfkill patches haven't landed
yet (again, scheduled for 2.6.27)

2) Intel-based wireless cards driven by ipw drivers send out a steady
stream of background scan events, which causes any process listening for
WEXT events to wake up.  Somewhat fixed for ipw2200 in 2.6.24 and later
by 0b5316769774d1dc2fdd702e095f9e6992af269a, but still wakes up all WEXT
listeners every 4 seconds

3) Have to poll the driver every so often (every 6 seconds right now
maybe?) to get signal strength information; I'd love it if drivers would
just send this out over netlink or WEXT or whatever every few seconds.
Not sure if people want that kernel-side though since there's not always
a listener and the frequency of events should be somewhat selectable.

> 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

Interesting... I have no idea why it would be a significant wakeup
source.  It just listens on the D-Bus system bus, and uses the glib
child-watch functionality to monitor vpnc child process state.

Dan

>  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
>  2397 |   16      0      0      0      0       0      0| libvirtd
>  2725 |   63    214      0      4      0       0      0| Xorg
>  2150 |   42      0      0      0      0       0      0| setroubleshootd
>  3010 |   47      0      0      0      0       0      0| gnome-settings-
>  3040 |  111      0      0      0      0       0      0| metacity
>  3526 |   37      0      0      0      0       0      0| notification-da
>  3085 |   49      0      0      0      0       0      0| wnck-applet
>  3043 |   50      0      0      0      0       0      0| gnome-screensav
>  3042 |   26      0      0      0      0       0      0| nautilus
>  3050 |    8      0      0      0      0       0      0| evince
>  9120 |    0      5      0      0      0       0      0| vpnc
>  3342 |   11      0      0      0      0       0      0| clock-applet
>  3329 |    0      6      0      0      0       0      0| pam_timestamp_c
>  2337 |    0      7      0      0      0       0      0| sendmail
>  2132 |    0      0      0      0     33       0      0| automount
>  2958 |    0      3      0      0      0       0      0| ssh-agent
>  2118 |    1      0      0      0      0       0      0| dbus-daemon
>  5732 |    1      0      0      0      0       0      0| gnome-vfs-daemo
> 29394 |   68    131      0      0     65       0      0| firefox
>  2105 |    1      0      0      0      0       0      0| audispd
>  1979 |    0      1      0      0      0       0      0| rsyslogd
> 
> 
> As you can see, not all programs are equally bad and proprietary ones
> (here: flash) are the worst.
> 
> Still, since the script records wakeups due to timeouts almost all
> mentions on this list are bad.  Programs should be woken based on
> events.  They shouldn't poll data (which is what usually happens after a
> timeout).
> 
> I would hope the package maintainers can find some time and look at the
> issues.  Maybe at least document them in a BZ.  I might try to do the
> latter myself but given the large number of packages involved I'll most
> likely be able to cover just a few packages.  IMO it should be a release
> criteria that a program does use polling.
> 
> - --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkh7y9oACgkQ2ijCOnn/RHTW6wCfWzYOn3AvjLvJ5mwWjSZwr8tX
> Z84An2YYvqd9f2fkPGenE5uhDDdsan3y
> =VWLu
> -----END PGP SIGNATURE-----
> plain text document attachment (timeout.stap)
> # Copyright (C) 2008 Red Hat, Inc.
> # Written by Ulrich Drepper <drepper@xxxxxxxxxx>
> global process
> global poll_timeouts
> global epoll_timeouts
> global select_timeouts
> global itimer_timeouts
> global nanosleep_timeouts
> global futex_timeouts
> global signal_timeouts
> 
> probe kernel.function("do_sys_poll").return {
>       if ($return == 0) {
>          p = pid()
> 	 if (!(p in process))
>             process[p] = execname()
>       	 poll_timeouts[p]++
>       }
> }
> 
> probe kernel.function("do_select").return {
>       if ($return == 0) {
>          p = pid()
>          if (!(p in process))
>             process[p] = execname()
>       	 select_timeouts[p]++
>       }
> }
> 
> probe kernel.function("sys_epoll_wait").return {
>       if ($return == 0) {
>          p = pid()
>          if (!(p in process))
>             process[p] = execname()
>       	 epoll_timeouts[p]++
>       }
> }
> 
> probe kernel.function("do_futex").return {
>       if ($return == -110) {
>          p = pid()
>          if (!(p in process))
>             process[p] = execname()
>       	 futex_timeouts[p]++
>       }
> }
> 
> probe kernel.function("hrtimer_nanosleep").return,
>       kernel.function("sys_clock_nanosleep").return {
>       if ($return == 0) {
>          p = pid()
>          if (!(p in process))
>             process[p] = execname()
>       	 nanosleep_timeouts[p]++
>       }
> }
> 
> probe kernel.function("it_real_fn") {
>         p = pid()
>         itimer_timeouts[p]++
>         if (!(p in process))
>             process[p] = execname()
> }
> 
> probe kernel.function("sys_rt_sigtimedwait").return {
>       if ($return == -11) {
>          p = pid()
>          if (!(p in process))
>             process[p] = execname()
>       	 signal_timeouts[p]++
>       }
> }
> 
> probe kernel.function("do_exit") {
>         p = pid()
>         if (process[p] == execname()) {
>                 delete process[p]
> 		poll_timeouts[p] = 0
>   		epoll_timeouts[p] = 0
>   		select_timeouts[p] = 0
>   		itimer_timeouts[p] = 0
>   		futex_timeouts[p] = 0
>   		nanosleep_timeouts[p] = 0
> 		signal_timeouts[p] = 0
>         }
> }
> 
> probe timer.ms(1000) {
>         printf("\033[2J\033[1;1H") /* clear screen */
>         printf ("  uid |   poll  select   epoll  itimer   futex nanosle  signal| process\n");
>         foreach (p in process) {
> 		if (poll_timeouts[p] != 0 || select_timeouts[p] != 0
>                     || epoll_timeouts[p] != 0 || itimer_timeouts[p] != 0
>  		    || futex_timeouts[p] != 0 || nanosleep_timeouts[p] != 0
> 		    || signal_timeouts[p] != 0)
>                 	printf ("%5d |%7d %7d %7d %7d %7d %7d %7d| %-.38s\n", p,
>                         	poll_timeouts[p], select_timeouts[p],
>                         	epoll_timeouts[p], itimer_timeouts[p],
> 				futex_timeouts[p], nanosleep_timeouts[p],
>                         	signal_timeouts[p], process[p])
>         }
> }
> -- 
> fedora-devel-list mailing list
> fedora-devel-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux