Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754417AbbDTU4o (ORCPT ); Mon, 20 Apr 2015 16:56:44 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:43177 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752173AbbDTU4n (ORCPT ); Mon, 20 Apr 2015 16:56:43 -0400 Date: Mon, 20 Apr 2015 22:56:38 +0200 From: Greg Kroah-Hartman To: Richard Weinberger Cc: 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: <20150420205638.GA3015@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4083 Lines: 92 On Mon, Apr 20, 2015 at 10:43:19PM +0200, Richard Weinberger wrote: > David, > > On Thu, Apr 16, 2015 at 8:20 PM, David Herrmann wrote: > > Hi > > > > On Wed, Apr 15, 2015 at 8:18 PM, Linus Torvalds > > wrote: > >> On Wed, Apr 15, 2015 at 11:11 AM, Greg Kroah-Hartman > >> wrote: > >>> On Wed, Apr 15, 2015 at 01:33:27PM -0400, Steven Rostedt wrote: > >>>> > >>>> I'll argue that you can't fix the later one. One thing that I've observed over > >>>> the years of having faster computers is, as soon as you make it faster, people > >>>> will write slower software. > >>>> > >>>> Currently the issue is that we have thousands of dbus queries, you make dbus > >>>> 10x faster, I guarantee that people will write software with 10 thousand dbus > >>>> queries and we are no better off than we are today. > >>> > >>> Then they get to buy a faster machine :) > >> > >> Is there actually a performance issue? > >> > >> I've seen this claimed, but I have never seen any actual numbers. What > >> speeds up? By how much? is it actually measurable? > > > > For us, boot speed-up has not been the primary concern. The boot-time > > speedup that kdbus provides is unlikely to be significant on a generic > > linux distro today, given that nowadays the slow parts during bootup > > are firmware and hw initialization. The number of dbus messages sent > > during bootup of a general purpose Linux distro is relatively small. > > OTOH, during start-up of desktop environments, the dbus traffic is > > substantial, but until the porting of Qt and glib to kdbus has been > > completed and merged the real-world effect of this is minimal. > > > > Our interest in improved raw performance is mainly motivated by making > > dbus a viable protocol in situations where its semantics are > > appropriate. But for performance reasons one had to use custom > > protocols instead so far. Greg gave some examples in the cover letter, > > multi-media being the most obvious area where the ten-fold decrease in > > latency and the ability to efficiently copy large chunks of memory > > from one process to another is relevant. > > 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. > dbus my have issues which are worth to fix. But moving dbus more or > less in the kernel > seems overkill. Why do you think so? How is this code "overkill"? > So, what exactly are these issues and why can't we add new IPC > primitives to Linux which > allow a decent userland dbus? That's exactly what this patchset does. > To me kdbus seems much like an ad-hoc solution which is very dbus centric. Yes it is, but the "dbus centric" thing is a valid model that is quite useful and in use by a lot of programs as it solves a real problem. > IIRC Alan asked the same question. Yes, you can build everything off of tiny socket calls, but when you do that, you end up with the D-Bus userspace implementation we have today, with the issues that it has. By moving portions of that model into the kernel, as is done here, it solves a number of these issues, and allows for a lot more flexibility and things to be done that are impossible with the current model of trying to build on top of tiny ipc functions. The existing code is much stripped down from what you think of as a D-Bus daemon today, only the exact needed pieces are implemented here. Do you see anything wrong with the code as is submitted (aside from the issues that Al has pointed out that are being resolved already?) thanks, greg k-h -- 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/