Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965558AbbD1MuM (ORCPT ); Tue, 28 Apr 2015 08:50:12 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:33948 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965547AbbD1MuH (ORCPT ); Tue, 28 Apr 2015 08:50:07 -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 08:49:35 -0400 X-Google-Sender-Auth: c6cCMlpXm9BfKkdc6mLYUJu6c2U 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: 2123 Lines: 46 On Mon, Apr 27, 2015 at 6:00 PM, Linus Torvalds wrote: > If somebody wants to speed up dbus, they should likely look at the > user-space code, not the kernel side. To be more precise, your profile seems to show a lot of the gdbus (glib bindings) user space code. (And the blocking version of this benchmark *is* doing something ridiculous, by blocking for every round trip, which is the one performance mistake the docs say over and over not to make.) There are at least two other C bindings (a plain-C one in systemd and the original libdbus). If someone wanted to get the noise out of the picture I imagine the plain-C bindings in systemd might have a lot less in the way of allocations and locks than gdbus, though I haven't looked at them. Those systemd bindings are also the ones people asking for more performance are probably using (because they are talking about early boot, system services, etc.) > My guess is that pretty much the entirely of the quoted kdbus > "speedup" isn't because it speeds up any kernel side thing, it's > because it avoids the user-space crap in the dbus server. The dbus bus daemon doesn't link to any g_ functions, fwiw, when interpreting these profiles. Though nobody would claim the bus daemon is fast, it is on the order of a few times slower than a raw socket last I checked (which was a long time ago) ... here are some old threads: http://lists.freedesktop.org/pipermail/dbus/2004-November/001779.html http://lists.freedesktop.org/archives/dbus/2012-March/015024.html In 2004, the libdbus parsing/validation/malloc/etc. overhead was 2.5x a raw socket without the bus daemon, and about twice that with the bus daemon (since the daemon adds another read and another write per message). I'm not aware of any reason this would have changed dramatically, though it doesn't mean there isn't one. 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/