Bringing D-Bus Into The Linux Kernel

[phtpht]

If you claim to be concerned with performance but you're not concerned with memory usage or copies, you're an idiot. Memory may be "orders of magnitude faster than the rest of the system" but it's still orders of magnitude slower than the CPU.

I'm not sure if this was wrt my post but the point is I am not concerned. No sane person should give a damn if the "you've got mail" message ... which is how big? 100 bytes with a big reserve... is present one or five times in the memory, if it is backed by registers or cache or RAM, and absolutely not if advancing in this area means losing all memory/process protection that is in the OS.

[highlandsun]

If you claim to be concerned with performance but you're not concerned with memory usage or copies, you're an idiot. Memory may be "orders of magnitude faster than the rest of the system" but it's still orders of magnitude slower than the CPU.

[phtpht]

there are too many copy operations to forward a message thru the code

And what the heck is wrong with memory copying? The memory is already order of magnitude faster than the rest of the system. Is d-bus the interface that you would stream movies through or what? Normally d-bus is used for messages like "you have new mail".

[phtpht]

Oh yeah. Let's move everything into the kernel. Of course it *will* be faster when it requires no context switches. And you know what, it will be even faster if we ditch memory paging, pmode, etc and just use DOS. When will these people learn?

What happened to the "kernel is the small stable and secure thing that has sole access to the hardware"? If we put every other service into the kernel just because of performance it will become soon zero day heaven. The "context switch" thingy has a purpose and its delay is a price the wise guys of the past have decided is well worth its benefits.

[highlandsun]

Profile the code. DBus is still a pig. The header pasting and other stuff is utterly braindead, there are too many copy operations to forward a message thru the code. The fact that a roundtrip takes 4 system calls is bad enough relative to simple localhost multicast, but that's still not much overhead in the kernel. It's the other header munging crap that DBus does that makes it such a pig, and tossing that into the kernel won't make it suck any less.

The design was pretty stupid to begin with, all of these long strings for application/port addresses are inane. You already have to contact a central broker to establish your source and destination addresses; they should have used the central broker to map these string-form addresses into compact numeric ports (gee, like DNS and IP addresses, what a *novel* idea...) and only used the compact addresses in the actual message traffic. Only a moron would design a purely string-based addressing scheme for a communication protocol. In most DBus apps the string handles are larger than the actual application message data.

Idiots...

[liam]

I doubt it.

Everyone said that CORBA would suck for this role, and GNOME did it anyway. After many years of attempting to get it working (while DCOP/KParts worked and was used universally in KDE, at a fraction of the effort), they gave up and switched to dbus, which is very similar to dcop in both principles and implementation.

Certainily dbus worked, but it didn't do everything CORBA did. For one thing, CORBA was designed to handle distributed systems (something that will be increasingly useful - consider the recent issues the telepathy people have had extending their tubes with dbus). CORBA was able to handle components (something that I believe qt has built in, but that gtk+ hasn't). With the adoption of dbus Gnome has lost this ability. The big problem with CORBA was the lack of sugar bindings. I know the Novell people were able to work with it, but we still needed good documention for ORBit.
in short, dbus is nice and simple, as I've said, but Gnome needs more than it can provide, IMO.

[pingufunkybeat]

Although I like how clean dbus is, I wonder if we wouldn 't have been better with ORBit/CORBA (though it is massively more complicated)...

I doubt it.

Everyone said that CORBA would suck for this role, and GNOME did it anyway. After many years of attempting to get it working (while DCOP/KParts worked and was used universally in KDE, at a fraction of the effort), they gave up and switched to dbus, which is very similar to dcop in both principles and implementation.

[liam]

Read the comments to the original post.

Phoronix: Bringing D-Bus Into The Linux Kernel

Alban Crequy, a Maemo developer, for the past several weeks have been working on bringing D-Bus directly into the Linux kernel. Why? Huge performance improvements...

http://www.phoronix.com/vr.php?view=ODYwNA

This isn't going into the kernel as it is now.
DBus IS a bottleneck when processes are being overly verbose. The coolest idea I saw in the comments was of using the linux virtual networking facilities to model dbus, and then you have the security bonus in using an iptables-like setup, as well as QoS so you can expedite high priority messages. Cool.
Someone also made the excellent point about the using xml as the dbus language. Although messages, on average, are pretty short, something a wee bit more terse would seem to be in order, especially with many processes vying for access to the daemon.
Although I like how clean dbus is, I wonder if we wouldn 't have been better with ORBit/CORBA (though it is massively more complicated)...

Best/Liam

[tettamanti]

If what PinguFunkyBeat says is true, that dbus is unoptimized, then I do think that they should do some work there before taking it to the kernel.

From what I gather from [1] dbus not only validates, but also partially rewrites the messages as they pass through. In a RO scenario (which includes validation) it would be possible to use tee and splice to avoid the copy (but not the CS).

[1] http://alban.apinc.org/blog/2010/09/...kernel-faster/

[fabiank22]

Damn Edit Limit.

Anyway from the D-Bus faq:

How does D-Bus differ from other interprocess communication or networking protocols?


Keep in mind, it is not only an IPC system; it also includes lifecycle tracking, service activation, security policy, and other higher-level structure and assumptions.

And:

D-Bus communication with the intermediate bus daemon should be (and as last profiled, was) about twice as slow as one-to-one mode, because a round trip involves four socket reads/writes rather than two socket reads/writes.

The overhead comes from a couple of places; part of it is simply "abstraction penalty" (there are layers of code to support multiple main loops, multiple transport types, security, etc.). Probably the largest part comes from data validation (because the reference implementation does not trust incoming data). It would be simple to add a "no validation" mode, but probably not a good idea all things considered.

Raw bandwidth isn't the only concern; D-Bus is designed to enable asynchronous communication and avoid round trips. This is frequently a more important performance issue than throughput.