D-Bus optimizations

[Bart Cerneels]

On 14-03-12 17:08, Colin Walters wrote:
> On Wed, 2012-03-14 at 10:03 +0100, Bart Cerneels wrote:
>
>> Context switches is the biggest single problem to be solved since it
>> causes priority inversions. The anecdotal case was just to point out
>> the underlying architectural problem causes very real bugs. Don't think
>> it's the only project stumbling on this, just the best understood.
>>
>> Here is some supporting material:
>> http://shorestreet.com/sites/shorestreet.com/files/dbus-perf-report-0.9.9.pdf
>> Notice the heavy emphasis on priority and scheduling.
>
> Pretty good document - thanks!  A few random comments, no particular
> order:
>
> *) PLT overhead: We could apply -Bsymbolic-functions (like GLib does)
>     for the daemon and library pretty easily.
> *) Skeptical of the "break DBus up into independent features" idea...
>     that sounds like it'd create a compatibility Matrix From Hell.  What
>     would you do if one client desired total ordering but the other
>     didn't care, etc?
>
> So skipping down to the end where you propose a "hybrid" approach
> starting with the "D-Bus Proxies".  I'm uncertain how it solves the
> priority inversion problem unless we also dispense with total ordering.
> If for example upower wants to send a "battery low" signal, the signal
> gets queued out to the proxy, which then determines the recipients, but
> in the current semantics if some other process runs at a different
> priority level, the proxy still needs to block in order to write the
> signal.
>
> Also with D-Bus Proxies we'd be taking a step backwards on context
> switching initially =( This then gets to the claim that shared memory
> will fix that, but after all of this work it seems to me that we're
> almost just back to where we started almost - we could just do the
> equivalent thing by multi-threading dbus-daemon, no?

This document is already a bit old and it's proposed solution is not the 
basis of what Rodrigo, Javier and I are now doing for the GENIVI DBus 
improvement project at Collabora. Neither of us is co-author either.

We didn't think the client-side dbus proxies were a good idea either for 
the same reasons.
We are currently talking about a proxy, but this is for backwards 
compatibility in the daemon. It will connect the old-style AF_UNIX 
STREAM socket with the new system we are creating.

As for "breaking up features": this is not something that can be done 
post-hoc but should have been part of the original architecture. If 
there ever is a major, client breaking, re-architecture we'll need to 
keep all that and more in mind.

>
> What I keep coming back to is basically that we could make things
> noticeably better if we dropped the total ordering guarantee.  I'm not
> sure at all how to do that sanely though - it could be a negotiated
> "feature" but would people really opt in?
>

Yes, it would indeed make routing a lot easier with more options for 
transports as well. We've identified a few sets of services that will 
break without total ordering. An obvious one is the Telepathy 
architecture because of the inter-dependence of DBus services.
A possible solution is to join services that require it in a logical 
group which enforces message ordering strictly, but only in that group.
In the first (and unfortunately rejected) patch adding multicast to 
AF_UNIX [1] we had this possibility by using different groups per 
interconnected set of services.

[1] http://blogs.gnome.org/rodrigo/2012/02/27/d-bus-optimizations/