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 09:44:34 -0400
From:	Havoc Pennington <hp@...ox.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	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 Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> The real problems seem to be in dbus memory management (suggestion:
> keep a small per-thread cache of those message allocations) and to a
> smaller degree in the crazy utf8 validation (why the f*ck does it do
> that anyway?), with some locking problems thrown in for good measure.
>

I would say there are two distinct performance topics here.

A. is the fixed overhead of various bindings (which may well vary a
lot by binding). This is parsing, validation, allocation, locking,
whatever. It tends to be "per message operation" (read/parse or
marshal/write of a message).

B. is how many of these "message operations" (read/parse,
marshal/write) are happening.

To make A*B smaller, one can reduce either A or B.

The kdbus idea seems to be mostly about B, eliminating the bus
daemon's read/parse and marshal/write, and reducing it to only one
marshal/write by the sender and one read/parse by the recipient
without the daemon in between.

People have worked on A for clients, by doing the systemd binding for
example, but perhaps they have been reluctant to work on the bus
daemon itself to improve A for the bus because they felt solving B
would involve eliminating the bus daemon anyway. If you are planning
to solve B via kdbus, then optimizing the bus daemon itself would be a
waste of time (A only matters for clients, not the bus, in kdbus
world).

That email I linked earlier
(http://lists.freedesktop.org/archives/dbus/2012-March/015024.html )
has many suggestions on A for the bus daemon itself, but of course
taking the bus daemon out of the equation would be more effective than
any amount of optimizing it.

A. is kind of a realm of many choices - there are tons of bindings,
and people can decide if they want the convenient-but-malloc-happy
glib ones, or the more traditional C style of systemd, or Python or
Java or JavaScript or whatever ... this is an area where people can
make the tradeoff they want. But everyone is "stuck" with the bus
daemon (or kdbus) since it has to be shared among clients, of course.

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/