Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753058AbbDUJIK (ORCPT ); Tue, 21 Apr 2015 05:08:10 -0400 Received: from mail.sig21.net ([80.244.240.74]:45015 "EHLO mail.sig21.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752452AbbDUJIF (ORCPT ); Tue, 21 Apr 2015 05:08:05 -0400 Date: Tue, 21 Apr 2015 11:07:21 +0200 From: Johannes Stezenbach To: Richard Weinberger Cc: Greg Kroah-Hartman , David Herrmann , Linus Torvalds , Steven Rostedt , One Thousand Gnomes , Jiri Kosina , Al Viro , Borislav Petkov , Andy Lutomirski , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150421090721.GB20838@sig21.net> References: <20150420205638.GA3015@kroah.com> <55356CC1.1040301@nod.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55356CC1.1040301@nod.at> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-21-Score: -2.9 (--) X-Spam-21-Report: No, score=-2.9 required=8.0 tests=ALL_TRUSTED=-1,BAYES_00=-1.9,URIBL_BLOCKED=0.001 autolearn=ham Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2884 Lines: 64 On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote: > Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman: > >> In which situation on a common Linux system is the current dbus too slow today? > >> I've never seen a issue like "Oh my system is slow because dbus is > >> eating too much CPU cycles". > > > > See the original email which explained all of the things we can not do > > with D-Bus, some of which are due to speed, that can now be done with the > > kdbus code. > > okay, let's do it together. > > 1. Performance > You write: > "DBus is not used for performance sensitive applications because DBus is slow. > We want to make it fast so we can finally use it for low-latency, > high-throughput applications." > > Which applications exactly? > This reads to me like a solution for a non-existing problem. This is the line of thinking I was aiming at during a previous review cycle. Basically, as Havoc outlined in his mail explaining the design decisions, he traded speed for simplicity and chose the slowest possible messaging topology (everything goes through a central broker). That makes sense because, to quote from his mail: http://article.gmane.org/gmane.linux.kernel/1931720 > Message passing or IPC isn't really the most important part of dbus. > Process lifecycle tracking and discovery are more important. I asked for performance numbers and got this reply from David Herrmann: http://article.gmane.org/gmane.linux.kernel.api/7636 My line of thinking had been to amend DBus with optional direct client/server communication for the performance critical cases, since I believe those cases are RPC calls and not other types of messaging (see also the "Performance" section in the cover letter of this thread). (My other line of thinking had been: if you need performance, don't use DBus e.g. in the case of the tiny ARM systems sending hundreds of thousands of messages during boot, quoted by Greg.) Now, after reading Havoc's description of the DBus design trade-offs, I have doubts that modifiying the DBus architecture in userspace to speed it up is a good thing. OTOH I am still convinced kdbus is the wrong solution, for the sole reason called gut feeling. There is nothing about the kdbus API that makes me go "oh nice, elegant, I want to use it". And the kdbus authors seem to agree and tell you you should only ever use it via a library like sd-bus and try to justify it by comparing it to ALSA :-( The ideas discussed among Alan, Andy and Al, even if ad-hoc and yet immature, immediately seemed to be much more appealing to me. I hope something real comes out of that. Johannes -- 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/