Starting the kdbus discussions

[Lukasz Skalski]

On 01/16/2014 06:28 PM, Lennart Poettering wrote:
> 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
>

Hi,

As I mentioned here [1] I'm working on kdbus support for glib. Project 
is almost ready, so I'll try prepare tommorow simple benchmark for it 
(the same application running with kdbus and normal socket transport).

-- 
Lukasz Skalski
Samsung R&D Institute Poland
Samsung Electronics
l.skalski at partner.samsung.com