[lkml]   [2015]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach <> 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

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.


 \ /
  Last update: 2015-04-21 16:21    [W:0.251 / U:1.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site