Re: [GIT PULL] kdbus for 4.1-rc1

[Havoc Pennington]

On Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/