Message-ID: <CAEntwhGfpfAPH7dy1giec2LYjYxxDXM_PzKoT4Zn9YURPayrzg@mail.gmail.com>
Date:	Tue, 21 Apr 2015 09:37:44 -0400
From:	Havoc Pennington <hp@...ox.com>
To:	Johannes Stezenbach <js@...21.net>
Cc:	Richard Weinberger <richard@....at>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Kosina <jkosina@...e.cz>,
	Al Viro <viro@...iv.linux.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

Hi,

On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach <js@...21.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists