Canonical System Image

Bug #1480844
Comment #9

Comment 9 for bug 1480844

Revision history for this message

Michael Terry (mterry) wrote on 2015-08-24:

More testing!

So when dbus-daemon spikes, other spiking programs (at ~30% CPU) I've seen are NetworkManager, posclientd, and initctl (at various times).

But I did note that initctl stayed around longer than the others. That coupled with the frequent ping-ponging of cpu-device-online and cpu-device-offline was making me wonder if maybe we weren't letting the CPU properly sleep because of all the DBus noise we created when noticing that the CPU was trying to sleep (or at least were DoSing the DBus channel with such notices).

I'm not 100% on that theory, since I thought DBus was smart about sending signals only when there was a listener (though my use of dbus-monitor might count there and be giving us non-realistic results).

But anyway. On that theory, I tried commenting out [1] the bit in upstart where we send DBus signals for each upstart signal. I'm not sure anyone uses that functionality. Most code uses upstart directly.

With that, my spikes were much shorter. Only saw dbus-daemon go to 75%, instead of 100%. And initctl never spiked. (NetworkManager and posclientd did still.) The network indicator gave quicker feedback about switching between wifi/3G, presumably because it wasn't blocked on DBus as much.

I'm not entirely convinced that these short-ish (~30s) spikes I've been testing with are the same cause as the longer-term spikes this bug originated with (and I've seen before). Needs more testing. I'll try to use my patched phone around town more.

And even if this patch does fix it, it's a big hammer with unknown side effects. A more elegant solution is desirable.

[1] Upstart patch:

        NIH_LIST_FOREACH (control_conns, iter) {
@@ -1294,6 +1294,7 @@
                NIH_ZERO (control_emit_event_emitted (conn, DBUS_PATH_UPSTART,
                                                            event->name, event->
        }
+*/
}

/**

More testing!

So when dbus-daemon spikes, other spiking programs (at ~30% CPU) I've seen are NetworkManager, posclientd, and initctl (at various times).

But I did note that initctl stayed around longer than the others.  That coupled with the frequent ping-ponging of cpu-device-online and cpu-device-offline was making me wonder if maybe we weren't letting the CPU properly sleep because of all the DBus noise we created when noticing that the CPU was trying to sleep (or at least were DoSing the DBus channel with such notices).

But anyway.  On that theory, I tried commenting out [1] the bit in upstart where we send DBus signals for each upstart signal.  I'm not sure anyone uses that functionality.  Most code uses upstart directly.

With that, my spikes were much shorter.  Only saw dbus-daemon go to 75%, instead of 100%.  And initctl never spiked.  (NetworkManager and posclientd did still.)  The network indicator gave quicker feedback about switching between wifi/3G, presumably because it wasn't blocked on DBus as much.

I'm not entirely convinced that these short-ish (~30s) spikes I've been testing with are the same cause as the longer-term spikes this bug originated with (and I've seen before).  Needs more testing.  I'll try to use my patched phone around town more.

And even if this patch does fix it, it's a big hammer with unknown side effects.  A more elegant solution is desirable.

[1] Upstart patch:

=== modified file 'init/control.c'
--- init/control.c      2014-08-14 11:19:43 +0000
+++ init/control.c      2015-08-24 20:33:12 +0000
@@ -1284,7 +1284,7 @@
 control_notify_event_emitted (Event *event)
 {
        nih_assert (event != NULL);
-
+/*
        control_init ();
 
        NIH_LIST_FOREACH (control_conns, iter) {
@@ -1294,6 +1294,7 @@
                NIH_ZERO (control_emit_event_emitted (conn, DBUS_PATH_UPSTART,
                                                            event->name, event->
        }
+*/
 }
 
 /**