Starting the kdbus discussions

[Lennart Poettering]

On Fri, 17.01.14 14:27, Lukasz Skalski (l.skalski at partner.samsung.com) wrote:

> +--------------+--------------------+--------------------+
> |              |    Elapsed time    |    Elapsed time    |
> | Message size |  GLIB WITH KDBUS   | GLIB + DBUS_DAEMON |
> |              |      SUPPORT       |                    |
> +--------------+--------------------+--------------------+
> | 1000 x 4kB   |     1.351737 s     |     1.870417 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 8kB   |     1.349266 s     |     1.857693 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 16kB  |     1.383427 s     |     2.219304 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 32kB  |     1.358608 s     |     2.542795 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 64kB  |     1.878409 s     |     3.062035 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 128kB |     2.265555 s     |     4.043454 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 256kB |     3.112191 s     |     6.657750 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 512kB |     3.383699 s     |    11.400224 s     |
> +--------------+--------------------+--------------------+
> | 1000 x 1MB   |     4.703610 s     |    19.041988 s     |
> +--------------+--------------------+--------------------+

This all includes the latency introduced by gdbus' extra thread all
messages are bumped off?

Note that libsystemd-bus clients will probably get much higher
throughput, since we will not involve an extra thread in everything,
thus halving the number of context switches.

I am pretty sure that the dbus thread gdbus uses is a poor design
choice. It introduces extra latency for starters. However, what's
particularly bad about it is that it really breaks any attempts of
teaching gdbus prio inheritance magic. 

In upstream kdbus we are working on adding a synchronous (blocking)
method call ioctl, which should lower the overhead of remote method
calls a bit (one syscall per method call on the client side, and two on
the server side, which brings us very close to binder, which can do this
in two altogether) and opens the door for gifting CPU timeslices to the
server and doing priority inheritance. All that work is pointless if
gdbus always indirects method calls via an additional thread.

That all said, fixing this poor design choice in gdbus is probably
something to fix later, after kdbus support is finished for it.

Lennart

-- 
Lennart Poettering, Red Hat