Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030864AbbD1TUE (ORCPT ); Tue, 28 Apr 2015 15:20:04 -0400 Received: from mail-qg0-f54.google.com ([209.85.192.54]:33091 "EHLO mail-qg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030638AbbD1TUC (ORCPT ); Tue, 28 Apr 2015 15:20:02 -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 15:19:30 -0400 X-Google-Sender-Auth: q7LSRCON1SxaLn8MZCVRmAlqzWU Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: David Lang Cc: Linus Torvalds , 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: 2467 Lines: 54 On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote: > If the examples that are being used to show the performance advantage of > kdbus vs normal dbus are doing the wrong thing, then we need to get some > other examples available to people who don't live and breath dbus that 'so > things right' so that the kernel developers can see what you think is the > real problem and how kdbus addresses it. > > So far, this 'wrong' example is the only thing that's been posted to show > the performance advantage of kdbus. I'm hopeful someone will do that. fwiw, I would be suspicious of a broken benchmark if it didn't show: * the bus daemon means an extra read/parse and marshal/write per message, so 4 vs. 2 * the existence of the bus daemon therefore makes a message send/receive take roughly twice as long https://lwn.net/Articles/580194/ has a bit more elaboration about number of copies, validations, and context switches in each case. >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. If that isn't what a benchmark shows, then there's a mystery to explain... (one disruption to the ratio of course could be if the clients use a much faster or slower dbus lib than the daemon) As noted many times, of course this 2x penalty for the daemon was a conscious tradeoff - kdbus is trying to escape the tradeoff in order to extend usage of dbus to more use cases. Given the tradeoff, _existing_ uses of dbus seem to prefer the performance hit to the loss of useful semantics, but potential new users would like to or need to have both. That LWN article lists some other non-performance rationales for kdbus too, of course. Aside: earlier I referred to the systemd dbus client binding without a link, the link appears to be: http://cgit.freedesktop.org/systemd/systemd/tree/src/libsystemd/sd-bus 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/