Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031190AbbD1NpK (ORCPT ); Tue, 28 Apr 2015 09:45:10 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:36332 "EHLO mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031176AbbD1NpG (ORCPT ); Tue, 28 Apr 2015 09:45:06 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> From: Havoc Pennington Date: Tue, 28 Apr 2015 09:44:34 -0400 X-Google-Sender-Auth: X9UiSx-ujV1JtaKtVtHNQky3pE8 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Linus Torvalds Cc: Andy Lutomirski , Lukasz Skalski , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2371 Lines: 52 On Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/