Bringing D-Bus Into The Linux Kernel

[V!NCENT]

You guys seem to miss the point because almost everything these days uses dbus. So it is not _just_ Firefox or _just_ Jabber.

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.

[fabiank22]

Btw, what is wrong with IPC, which is already in the kernel? (At least I think it is.) I don't know much about the topic and wonder if there's something D-Bus does that IPC can't?

I assume you're talking about Inter Process-Communication, and yes, that's been part of POSIX since forever. However you're mistaking methods and implementations.

D-Bus is a method of IPC, as for the advantages of using it:

Messages received over a D-Bus connection get routed to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to users as if they are interacting with an object across the IPC connection, whether or not there is an object on the other side.

[RealNC]

Btw, what is wrong with IPC, which is already in the kernel? (At least I think it is.) I don't know much about the topic and wonder if there's something D-Bus does that IPC can't?

[fabiank22]

So what exactly do you think happens every time the X11 client inside the GTK library used by Firefox calls send() or receive() on the UNIX socket connecting it to the X server?

Surprise: Context switch to kernel mode.

Okay, guess I was wrong on that one, however once again we are talking about libraries, so the things that would change when firefox is moved to the kernel would be: zero.
Because it's not Firefox that uses the socket, it's GTK2 or XUL or QT or whatever lib you're using.

[sturmflut]

The power consumption of the N900, I have at most 2 days of battery.
A lot of experiments to get better battery life from the Maemo Wiki are about reducing context switches when the phone is not active.

Jesus, guys! Dbus is everywhere. 25% real world speedup? Get it here already!

(...)
so why hate it if it saves you batterylife?

Jesus!

Could we please gather some REAL numbers first, and make sure that all other parts of the dbus system are optimized? AFAICT the guy didn't even profile the application, and here he is claiming a kernel patch will solve everything.

Just look at his N900 benchmarks please: 10.000 ping-pong calls means 20.000 messages. The test takes about four seconds, which means a dbus round-trip takes just 400 microseconds - on a mobile CPU! Connecting to Jabber takes him twelve seconds. I heavily doubt connecting to Jabber generates 60.000 messages on dbus, so all this time must be spent somewhere else. The mentioned benchmark tool by Adrien Bustany doesn't build on Ubuntu 10.10 Beta, so I can't test it.

On every desktop system I've used to date dbus transports messages at an average rate of about one message every thirty seconds or less. Running KDE, network-manager and stuff.

I am absolutely sure dbus can be optimized in a number of other ways first. Like, finally find out why dbus is that much slower than CORBA or DCOP despite all three using UNIX sockets...

[pingufunkybeat]

The difference is that KDE switched rather quickly from DCOP to dbus, while Gnome has had a much slower migration away from the old Bonobo frameworks - I think the panel applet API changes in the upcoming 2.32 release are the last piece of core code to be migrated...

This is understandable, seeing how dbus was basically a drop-in replacement for dcop, working in almost exactly the same way (it was based on dcop concepts after all), while Bonobo was a mess which never worked in the first place.

Anyway, dbus is a free desktop standard, and making it Linux-only would be a really dumb thing to do.

[V!NCENT]

Jesus, guys! Dbus is everywhere. 25% real world speedup? Get it here already!

Oh it doesn't work remotely, so? Bringing it into the kernel doesn't mean that you have to use it or that it blocks you from using something else. I hope I need to remind no-one here that Linux on mda's is about a tenfold of the Linux desktop marketshare if not much greater, so why hate it if it saves you batterylife?

If the Linux kernel gets too complicated then time for HURD; It runs and I ran it 4-5 years ago. So either Linux is a mess or it should get in there. Realy...

[Ikipou]

I doubt this patch is about the speed of D-bus, but I think it is all about reducing context switch when a phone is in standby mode.

The power consumption of the N900, I have at most 2 days of battery.
A lot of experiments to get better battery life from the Maemo Wiki are about reducing context switches when the phone is not active.

[Delgarde]

DCOP is a KDE thing not a general userspace message bus and definitely old and has reached its limits, thus dbus was born. Also Gnome just started using dbus as well so it isn't just a KDE thing now any longer and it has gotten the same benefits as KDE did.

Wrong on two counts - dbus was never "just a KDE thing", and Gnome certainly hasn't "just started" using it. The guys who built it (Havoc and co) were long-time Gnome developers, and it was being used in Gnome apps pretty much from the start.

The difference is that KDE switched rather quickly from DCOP to dbus, while Gnome has had a much slower migration away from the old Bonobo frameworks - I think the panel applet API changes in the upcoming 2.32 release are the last piece of core code to be migrated...

[sturmflut]

Firefox communicating with X does not happen in Kernel-Mode.

So what exactly do you think happens every time the X11 client inside the GTK library used by Firefox calls send() or receive() on the UNIX socket connecting it to the X server?

Surprise: Context switch to kernel mode.


I would really like to see some profiling on the current dbus-daemon first which proves that those few context switches truly are the problem. X11 transmits far more messages via a similar mechanism, and it has been proven numerous times that UNIX socket communication does not account for performance problems.