Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966070AbbD1U0H (ORCPT ); Tue, 28 Apr 2015 16:26:07 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:32996 "EHLO mail-qc0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965258AbbD1U0D (ORCPT ); Tue, 28 Apr 2015 16:26:03 -0400 MIME-Version: 1.0 In-Reply-To: <20150428171840.GB11351@thunk.org> References: <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> <20150428171840.GB11351@thunk.org> From: Havoc Pennington Date: Tue, 28 Apr 2015 16:25:31 -0400 X-Google-Sender-Auth: pXs_4xyO-K0CZyrYUzE1IQd_uYI Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: "Theodore Ts'o" , Havoc Pennington , 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: 3328 Lines: 73 On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote: > So the question is if one of the justifications for moving the daemon > into kernel space is that it's performance is crap, then I think it is > useful to determine whether a fully optimized userspace daemon would > be good enough. > Yeah. I don't know how you answer that, because the answer is probably "it would be good enough for some things and not for other things." It depends on whether an app is sending enough data to be too slow, and it depends on the hardware, right. What I think we might know: the userspace:kernel time-to-send ratio should always be around 2:1, if both of them are similarly-implemented, because the userspace version has about 2x the work to do. The actual wall-clock time of course depends on the hardware and what's being sent. If there was a deviation from 2:1 in a benchmark, it might be because of implementation issues - so for example libdbus+dbus-daemon might be 3:1 or 5:1 to sd-dbus+kdbus, because sd-dbus isn't as bloated as libdbus, say. That isn't telling you anything about kernel vs. userspace architecture, the extra ratio above 2:1 is only telling you about userspace implementation quality. For purposes of deciding what to put in kernel - the differences between dbus client implementations (sd-dbus, libdbus, gdbus, etc.) seem like irrelevant noise to me. Re: the slippery slope to LDAP in the kernel - my questions would be things like 1) what are non-performance reasons to have dbus in the kernel, such as early boot or security considerations; 2) does LDAP in kernel give these kind of 2:1 gains; 3) is there a simpler way to get the 2:1 gain for dbus... Others can answer those better than I can. I _would_ say that dbus is more "generic" than something like LDAP; dbus is specific to the use-case of coordinating processes on a single machine, but it isn't specific to any particular application, and it's been used for lots of different applications. On my laptop, which is a pretty normal fedora 21 as far as I know: $ rpm -q --whatrequires 'libdbus-1.so.3()(64bit)' | wc -l 113 this omits anyone using a different binding, it's only libdbus users. > I find dbus to be extremely hard to debug when my desktop starts doing > things I don't want it to do. The fact that it might be flinging around hundreds > of thousands of messages, and that this is something we want to encourage, This particular argument doesn't resonate with me ... if dbus is hard to debug, it's not as if "ad hoc application-specific sidechannel somebody cooked up" is going to be easier. People aren't usually making up data to send around just because they can. If they need to send an audio stream, and dbus is too slow, they'll send it another ad hoc way, but it ultimately has to get sent. Same for most data, it is the size it is and it needs to go where it needs to go, for some what-the-user-wants-to-do kind of reason. If apps have to, they say "I'm sorry Dave I can't do that - you can't software-decode 4K video on your 300mhz ARM" - 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/