linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Apr 2015 13:43:24 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Havoc Pennington <hp@...ox.com>
Cc:	David Lang <david@...g.hm>, Andy Lutomirski <luto@...capital.net>,
	Lukasz Skalski <l.skalski@...sung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 28, 2015 at 12:19 PM, Havoc Pennington <hp@...ox.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
--
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/