Starting the kdbus discussions

[Lennart Poettering]

On Fri, 10.01.14 13:47, Thiago Macieira (thiago at kde.org) wrote:

> On sexta-feira, 27 de dezembro de 2013 01:04:19, Lennart Poettering wrote:
> > Heya,
> > 
> > We today reached a milestone in kdbus development, that we have all the
> > bits in pieces in place to boot a full system with kdbus as system bus
> > and no dbus-daemon in the mix for it. The only missing bit is policy
> > enforcement, everything else is there.
> 
> Hi Lennart
> 
> Do you have any performance benchmarks done already? We're all technical here 
> and we understand the new architecture improvements are worth it, but have you 
> measured them?

Nope. 

I mean, what would a realistic benchmark even be? Currently you'd
compare apples and oranges, since only libsystemd-bus is a native kdbus
frontend, gdbus and libdus1 aren't. And as it turns out libsystemd-bus
already is twice as fast against dbus-daemon as libdbus1 is according to
some automotive guys who measured it. In addition, since most of the
system curretnly connects via the proxy, you can't have any "realistic"
benchmark, since we pay a heavy cost for remarshalling everything all
the time...

We certainly want this to be efficient and stuff, but our primary goal
is certainly elegance and simplicty, and we'll make things slower if
needed, if it makes our code nicer... We really don't want to be in the
"let's optimize the last bit out of it" game, we want something that is
maintainable and naturally effeicient.

Classic socket dbus does 10 message copies, 4 full message validations, and 4
process context switches per full duplex method invocation. kdbus does 2
or less copies, 2 full message validations, and 2 process context
switches for the same. With that being the case I feel quite comfortable
that we'll be tons faster even in the worst case.

Note that we did some benchmarks for specific questions, but they'll not
compare anything with dbus-daemon of old. For example, we have simple
ping-pong tests and a tool to dtermine where the memfd mapping overhead
becomes cheaper than copying messages. Kay and the Samsung guys profiled
kdbus quite a bit to optimize a specifc issue on ARM devices, where
their incoherence memory model resulted in bad performance. 

Anyway, if you care about performance measurements I certainly welcome
any work on that!

Lennart

-- 
Lennart Poettering, Red Hat