Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

On Mon, Apr 27, 2015 at 6:00 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> If somebody wants to speed up dbus, they should likely look at the
> user-space code, not the kernel side.

To be more precise, your profile seems to show a lot of the gdbus
(glib bindings) user space code. (And the blocking version of this
benchmark *is* doing something ridiculous, by blocking for every round
trip, which is the one performance mistake the docs say over and over
not to make.)

There are at least two other C bindings (a plain-C one in systemd and
the original libdbus).

If someone wanted to get the noise out of the picture I imagine the
plain-C bindings in systemd might have a lot less in the way of
allocations and locks than gdbus, though I haven't looked at them.
Those systemd bindings are also the ones people asking for more
performance are probably using (because they are talking about early
boot, system services, etc.)

> My guess is that pretty much the entirely of the quoted kdbus
> "speedup" isn't because it speeds up any kernel side thing, it's
> because it avoids the user-space crap in the dbus server.

The dbus bus daemon doesn't link to any g_ functions, fwiw, when
interpreting these profiles. Though nobody would claim the bus daemon
is fast, it is on the order of a few times slower than a raw socket
last I checked (which was a long time ago) ... here are some old
threads:

http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html
http://lists.freedesktop.org/archives/dbus/2012-March/015024.html

In 2004, the libdbus parsing/validation/malloc/etc. overhead was 2.5x
a raw socket without the bus daemon, and about twice that with the bus
daemon (since the daemon adds another read and another write per
message). I'm not aware of any reason this would have changed
dramatically, though it doesn't mean there isn't one.

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/