Re: [GIT PULL] kdbus for 4.1-rc1

Linus Torvalds
2015-04-28T20:43:30Z

On Tue, Apr 28, 2015 at 12:19 PM, Havoc Pennington <hp@pobox.com> wrote:
>
> From what I can tell, the core performance claim for kdbus is that for
> a userspace daemon to be a routing intermediary, it has to receive and
> re-send messages. If the baseline performance of IPC is the cost to
> send once and receive once, adding the daemon means there's twice as
> much to do (1 more receive, 1 more send). However fast you make
> send/receive, the daemon always means there are twice as many
> send/receives as there would be with no daemon.

HOWEVER.

That's only a good optimization strategy if the code is optimized to begin with.

If the code spends 10x as much time in user space in "overhead" as it
actually spends in the kernel, the proper place to optimize is to get
rid of the 10x. That will make things much faster.

Once user space is lean and mean, at that point do I believe that "ok,
let's add kernel code for the last bit of performance". But as it is
right now, anybody who works on kdbus and claims that _performance_ is
the reason for their work is just looking at teh wrong piece of the
puzzle.

Now, there may be *other* reasons why kdbus is a good idea. But quite
frankly, every time somebody asks "why", performance seems to be one
of the main answers.

And quite frankly, that *stinks*.

Do proper optimizations of the actual real costs before starting to
work on kernel stuff. It's *stupid* to add a kernel driver to get 2x
improvement, when there's a 10x bloat in user space.

Is that really so hard to see? I don't think it is at *all*
appropriate to say "we're a f*cking bloated pig, but we're too lazy to
fix the bloat and the primary performance problems, so we'll add a
kernel interface to partially hide the issue".

That is particularly true because if you fix the user-level
performance problems, you may notice that there was something stupid
in the interfaces, and some of the kernel interface design was wrong.

Linus