| 2012-02-17 11:19:17 |
Colin Ian King |
description |
I've noticed that nm-applet is polling at ~10Hz. This seems to occur only when I am either connected to the network (ethernet or wireless). A strace of nm-applet is as follows:
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 100) = 0 (Timeout)
read(4, 0x7fff27127870, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 0) = 0 (Timeout)
read(4, 0x7fff27127870, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 100) = 0 (Timeout)
read(4, 0x7fff27127870, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 0) = 0 (Timeout)
So it seems we have a poll using 100 millisecond timeout and also a 0 millisecond timeout. The 0 millisecond timeout is basically a busy poll which seems a little excessive. The 100 millisecond timeout is the root cause of the 10Hz events/second wakeup.
This is causing excessive wakeups which keeps the CPU out of deep C sleep states and hence reduces battery life. Can this be fixed? |
I've noticed that nm-applet is polling at ~10Hz. This seems to occur only when I am only connected to the network (ethernet or wireless). A strace of nm-applet is as follows:
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 100) = 0 (Timeout)
read(4, 0x7fff27127870, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 0) = 0 (Timeout)
read(4, 0x7fff27127870, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 100) = 0 (Timeout)
read(4, 0x7fff27127870, 16) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(3, 0x101e304, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}], 6, 0) = 0 (Timeout)
So it seems we have a poll using 100 millisecond timeout and also a 0 millisecond timeout. The 0 millisecond timeout is basically a busy poll which seems a little excessive. The 100 millisecond timeout is the root cause of the 10Hz events/second wakeup.
This is causing excessive wakeups which keeps the CPU out of deep C sleep states and hence reduces battery life. Can this be fixed? |
|
