D-Bus optimizations

[Rodrigo Moya]

On Tue, 2012-02-28 at 09:23 +0200, Alberto Mardegan wrote:
> On 02/27/2012 02:04 PM, Rodrigo Moya wrote:
> > Hi
> > 
> > Just published a blog entry[1] about some recent work we have been doing
> > at Collabora to optimize D-Bus. So could you please have a look and
> > comment on it?
> 
> Avoiding routing all the messages through one process (the D-Bus server)
> seems like a huge (at least 2x, I should think) optimization. Not only
> because of the data copies which are eliminated, but also for lower
> latency and avoiding running into a possible bottleneck when the D-Bus
> server is busy processing other messages.
> 
> I proposed something similar some time ago[0] (see my message to this ML
> dated 28/1/2012), but in that proposal I was not considering multicast
> sockets, and instead directly routing all messages in a p2p fashion.
> Which approach is better probably depends a lot on the kernel; whether
> the kernel is more efficient in routing messages to a single socket (out
> of N open sockets), or performing the filtering for a multicast socket.
> 
> But in any case, I'm happy to see something moving in this front, so
> please keep up the good work! :-)
> 
> A few questions:
> - Do you have some numbers on the performance?
>
we have numbers for the AF_DBUS solution, which are, IIRC, in Alban's
blog posts, but as I said in my blog, it wasn't very welcomed on the
kernel mailing list. But the improvements were huge, IIRC.

As I said in my answer to Colin, we have no real numbers yet for the
multicast branch, but we should soon. In theory, removing the daemon as
a proxy for all communications saves the context switches + extra
message copying/validation, so it should be quicker. Right now, the
filters don't work as expected on my branch, so we are getting lots of
extra traffic, making it slower than current D-Bus. But I'm working on
fixing that, and once fixed, it should be much quicker than current
D-Bus.

> - What happens if a message is sent to 3 clients, and one of them is
> hanging and doesn't read from the socket? Are also other clients
> affected, or can they continue receiving more messages?
>
right now, the kernel implementation will block the sender, but we are
looking for a better solution, so that we don't lose any messages.

> - Do you create only one multicast group for all clients in a D-Bus
> session, or one group per D-Bus service?
> 
one per bus, so 1 for session and 1 for system bus. We discussed having
multicast groups for each interface, but that would complicate things a
lot, as some clients might have to join several multicast groups.

cheers