Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

Hi,

On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach <js@xxxxxxxxx> wrote:
> My line of thinking had been to amend DBus with optional direct
> client/server communication for the performance critical
> cases, since I believe those cases are RPC calls and not other
> types of messaging (see also the "Performance" section in the
> cover letter of this thread).  (My other line of thinking had
> been: if you need performance, don't use DBus e.g. in the
> case of the tiny ARM systems sending hundreds of thousands of
> messages during boot, quoted by Greg.)
>

This has long been sort of the 'party line' and I've told many people
this on the dbus mailing list over the years (almost exactly what you
just said - that for performance-critical cases they should open a
direct socket or use something else or whatever). Usually this makes
app developers a little cranky because something that was going to be
easy in their mind just got harder.

I think the pressure to use dbus happens for several reasons, if you
use a side channel some example complaints people have are:

 * you have to reinvent any dbus solutions for security policy,
containerization, debugging, introspection, etc.
 * you're now writing custom socket code instead of using the
high-level dbus API
 * the side channel loses message ordering with respect to dbus messages
 * your app code is kind of "infected" structurally by a performance
optimization concern
 * you have to decide in advance which messages are "too big" or "too
numerous" - which may not be obvious, think of a cut-and-paste API,
where usually it's a paragraph of text but it could in theory be a
giant image
 * you can't do big/numerous multicast, side channel only solves the unicast

There's no doubt that it's possible to use a side channel - just as it
was possible to construct an ad hoc IPC system prior to dbus - but the
overall OS (counting both kernel and userspace) perhaps becomes more
complex as a result, compared to having one model that supports more
cases.

One way to frame it: the low performance makes dbus into a relatively
leaky abstraction where there's this surprise lurking for app
developers that they might have to roll their own IPC on the side or
special-case some of their messages.

it's not the end of the world, it's just that it would have a certain
amount of overall simplicity (counting userspace+kernel together) if
one solution covered almost all use-cases in this "process-to-process
comms on local system" scenario, instead of 90% of use-cases but too
slow for the last 10%. The simplicity here isn't only for app
developers, it's also for anyone doing debugging or administration or
system integration, where they can deal with one system _or_ one
system plus various ad-hoc side channels.

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/