Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

On Tue, Apr 28, 2015 at 1:19 PM, David Lang <david@xxxxxxx> wrote:
> If the examples that are being used to show the performance advantage of
> kdbus vs normal dbus are doing the wrong thing, then we need to get some
> other examples available to people who don't live and breath dbus that 'so
> things right' so that the kernel developers can see what you think is the
> real problem and how kdbus addresses it.
>
> So far, this 'wrong' example is the only thing that's been posted to show
> the performance advantage of kdbus.

I'm hopeful someone will do that.

fwiw, I would be suspicious of a broken benchmark if it didn't show:

* the bus daemon means an extra read/parse and marshal/write per
message, so 4 vs. 2
* the existence of the bus daemon therefore makes a message
send/receive take roughly twice as long

https://lwn.net/Articles/580194/ has a bit more elaboration about
number of copies, validations, and context switches in each case.

>From what I can tell, the core performance claim for kdbus is that for
a userspace daemon to be a routing intermediary, it has to receive and
re-send messages. If the baseline performance of IPC is the cost to
send once and receive once, adding the daemon means there's twice as
much to do (1 more receive, 1 more send). However fast you make
send/receive, the daemon always means there are twice as many
send/receives as there would be with no daemon.

If that isn't what a benchmark shows, then there's a mystery to
explain... (one disruption to the ratio of course could be if the
clients use a much faster or slower dbus lib than the daemon)

As noted many times, of course this 2x penalty for the daemon was a
conscious tradeoff - kdbus is trying to escape the tradeoff in order
to extend usage of dbus to more use cases. Given the tradeoff,
_existing_ uses of dbus seem to prefer the performance hit to the loss
of useful semantics, but potential new users would like to or need to
have both.

That LWN article lists some other non-performance rationales for kdbus
too, of course.

Aside: earlier I referred to the systemd dbus client binding without a
link, the link appears to be:
http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd/sd-bus

Havoc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/