org.freedesktop.DBus.Properties.GetAll

[David Zeuthen]

On Thu, 2007-04-12 at 19:04 -0400, David Zeuthen wrote:
> Maybe what we gain is just not worth the cost... I mean, if you have N
> servers [1] all emitting notifications they will be woken up _anyway_;
> so all this extra complexity would only save us from waking up the bus
> daemon.. so the savings would be going from N+1 to N. Probably not worth
> the cost.

Although the above is correct, it's not really interesting. What is more
interesting, however, is the number of actual wakeups and when they
happen.. and that clearly doubles unless we add the kind of complexity I
mentioned.

Then again, things like HAL and NM don't do that many wakeups per
second; it's (for HAL at least but I think NM too) also triggered by an
event from the kernel (no polling, well.. almost.. see [1]). Just run
"dbus-monitor --system" and examine the results.

So, even with taken this into account, I don't think we gain much on the
typical desktop system; most communication goes pretty much like this

 hardware -> kernel -> HAL -> message bus -> {zero or more clients}
                          ^^^^^
                            |
                        (this involves a roundtrip to the kernel too!)

so all the processes (kernel, HAL, message bus) will be woken up at
approximately the same time meaning that if the kernel is smart enough
it will run this code at approximately the same time and then go back
into a deep power state and remain there for many many milliseconds.

I guess I'm trying to say that I doubt that adding the complexity I
mentioned is not going to save much power (e.g. laptop battery life);
e.g. the extra wake up of the message bus daemon probably happens when
the CPU isn't in a deep power state *anyway*. It may be different for
ARM and other embedded architectures where context switches are
ridiculously expensive and it may affect battery life. Maybe Rob knows
some more about this.

Anyway, sorry for rambling; just thought it was interesting to note. Of
course, I'm not really an expert on CPU power management and how smart
the kernel is about these things; it's probably worth profiling this /
extracting clues from someone more knowledgeable.

     David


[1] : except for drives with removable media that is polled either every
2nd or 16th second - but even that will go away in the future with
SATA's AN mechanism. See
 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=halpolling

    David