DBus in the kernel?

[Schmottlach, Glenn]

Please don't forget that some of us aren't using D-Bus under Linux. It's easy to assume otherwise, but D-Bus has gained some measure of traction as an application bus under Win32 and in my situation, in an embedded environment running QNX (which is decidedly not Linux).

Some investigation we've done seems to indicate that the message bus marshalling/unmarshalling code, while generic and robust, may be very inefficiently implemented. I guess the design decision at the time was to err on the side of clarity and simplicity vs. raw performance. Not necessary a bad trade-off early in an implementation. We also take a decent hit with context switches which can be decidedly worse depending on the chip (e.g. ARM rather than generic x86).

Perhaps the first step is to truly find out what is slow and what is not. I suspect the initial suspicions may not pan out to be the real culprits after all. Before rushing off to implement the bus in the kernel (which makes it unusable for Win32/QNX ports), the infamous *someone* (e.g. not me ;-) should really measure the bus to find the weak spots. It's not a question of whether a kernel implementation will be faster (it will), it's a question of whether it will be significantly faster, more robust, and still be useful for the larger D-Bus community.

Glenn 

-----Original Message-----
From: dbus-bounces at lists.freedesktop.org [mailto:dbus-bounces at lists.freedesktop.org] On Behalf Of Michael Meeks
Sent: Tuesday, January 05, 2010 10:12 AM
To: Kimmo Hämäläinen
Cc: dbus at lists.freedesktop.org; hp at pobox.com
Subject: Re: DBus in the kernel?


On Tue, 2010-01-05 at 15:06 +0200, Kimmo Hämäläinen wrote:
> On Mon, 2010-01-04 at 22:55 +0100, ext Lennart Poettering wrote:
> > On Mon, 04.01.10 16:40, Havoc Pennington (havoc.pennington at gmail.com) wrote:
> > > What is the rationale for the bus itself in the kernel? Seems like one
> > > big pain in the ass, and I can't guess the motivation...
> > 
> > Primarily three things:
> > 
> > 1) Getting rid of the double context switch for each msg. Right now

	Soo - there seem to be, primarily a performance rational for this work,
which is all well and good; but have people profiled dbus to find what
is slow ? is it anything to do with the context switches (eg.) :-)

	Last I recall, (from the a11y measurements that Rob did), that
like-for-like, d-bus was ~2x slower than ORBit2 for the same, simple,
point-to-point (ie. not via the bus) synchronous call.
 
http://live.gnome.org/GAP/AtSpiDbusInvestigation#DBus_and_ORBit_Benchmarking

	If those numbers are still reasonable, then it suggests that the
context switching and pipe thrashing (laughably assuming ORBit2 is 100%
efficient and thus is pure kernel overhead) can only possibly be ~50% of
the cost, and that by doubling the speed of that we can maximally become
25% faster.

	Is it really worth re-writing the bus daemon, inside the kernel to get
a maximum of a 25% win ? :-) [ or are my numbers obsolete ]. Could we
not perhaps get a larger win from optimising _dbus_string_validate_utf8
further for ASCII, or (indeed) avoiding calling it in many more cases ?
(but of course, I havn't profiled recently either ;-).

	Finally, if the daemon is re-written to put in the kernel, hopefully
it'll be a BSD licensed blob (?) that can be re-used in those other
Unixen, such that we don't have to maintain the daemon  indefinitely in
parallel ? :-)

	Regards,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
dbus mailing list
dbus at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus