Re: [GIT PULL] kdbus for 4.1-rc1

[Johannes Stezenbach <js@sig21.net>]

On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
> Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
> >> In which situation on a common Linux system is the current dbus too slow today?
> >> I've never seen a issue like "Oh my system is slow because dbus is
> >> eating too much CPU cycles".
> > 
> > See the original email which explained all of the things we can not do
> > with D-Bus, some of which are due to speed, that can now be done with the
> > kdbus code.
> 
> okay, let's do it together.
> 
> 1. Performance
> You write:
> "DBus is not used for performance sensitive applications because DBus is slow.
> We want to make it fast so we can finally use it for low-latency,
> high-throughput applications."
> 
> Which applications exactly?
> This reads to me like a solution for a non-existing problem.

This is the line of thinking I was aiming at during a previous
review cycle.  Basically, as Havoc outlined in his mail explaining
the design decisions, he traded speed for simplicity and chose
the slowest possible messaging topology (everything goes through
a central broker).  That makes sense because, to quote from his mail:

http://article.gmane.org/gmane.linux.kernel/1931720
  > Message passing or IPC isn't really the most important part of dbus.
  > Process lifecycle tracking and discovery are more important.

I asked for performance numbers and got this reply from David Herrmann:
http://article.gmane.org/gmane.linux.kernel.api/7636

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.)

Now, after reading Havoc's description of the DBus design
trade-offs, I have doubts that modifiying the DBus architecture
in userspace to speed it up is a good thing.  OTOH I am
still convinced kdbus is the wrong solution, for the sole
reason called gut feeling.  There is nothing about the kdbus API
that makes me go "oh nice, elegant, I want to use it".  And
the kdbus authors seem to agree and tell you you should only ever
use it via a library like sd-bus and try to justify it by
comparing it to ALSA :-(

The ideas discussed among Alan, Andy and Al, even if ad-hoc
and yet immature, immediately seemed to be much more
appealing to me.  I hope something real comes out of that.


Johannes