My branch that disconnects from the signals on suspend and connect again on resume doesn't really fix this. I did make the system-settings code more efficient, but actually it doesn't connect to device-changed signals. Only device-added and device-removed. There are some places where we call some synchronous functions on upower, and when dbus-daemon is busy caused blocking issues.
I did some more testing tonight and found that even without system- settings running when the device sleeps, dbus-daemon uses quite a bit of CPU on resume. I saw between 24% and 87% without system-settings even running and would last for anywhere from 10s to over a minute. Attempting to start system-settings while dbus-daemon was busy would cause dbus-daemon load go up quite a bit and last longer. When dbus- daemon was the top culprit for the high load, upowerd was a distant #2, at just over 1%. However, once dbus-daemon settled down, upowerd would drop back to 0%. My new theory is dbus-daemon is spinning out of control because of upower, probably because indicator-power is still subscribed to it. When the device wakes, upowerd must be flooding dbus itself. When dbus- daemon is busy, it blocks or is just slow to respond. Another observation, I think this situation is more noticeable when the device is plugged into a computer, not just a wall charger. I didn't check the load on resume while plugged into a wall charger, but system- settings UI was much more responsive on waking up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1337200 Title: High CPU due to excessive device changed signals from upower To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1337200/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
