Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031209AbbD1XNJ (ORCPT ); Tue, 28 Apr 2015 19:13:09 -0400 Received: from mailrelay.lanline.com ([216.187.10.16]:11132 "EHLO mailrelay.lanline.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030966AbbD1XNF (ORCPT ); Tue, 28 Apr 2015 19:13:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21824.5086.446831.189915@quad.stoffel.home> Date: Tue, 28 Apr 2015 19:12:30 -0400 From: "John Stoffel" To: Havoc Pennington Cc: "Theodore Ts'o" , 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 Subject: Re: [GIT PULL] kdbus for 4.1-rc1 In-Reply-To: References: <20150423163616.GA10874@kroah.com> <20150423171640.GA11227@kroah.com> <553A4A2F.5090406@samsung.com> <20150428171840.GB11351@thunk.org> X-Mailer: VM 8.2.0b under 23.4.1 (x86_64-pc-linux-gnu) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5074 Lines: 108 >>>>> "Havoc" == Havoc Pennington writes: Havoc> 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. >> Havoc> Yeah. I don't know how you answer that, because the answer is Havoc> probably "it would be good enough for some things and not for Havoc> other things." It depends on whether an app is sending enough Havoc> data to be too slow, and it depends on the hardware, right. So what happens if we put kdbus into the kernel and it's still too slow? What then? Havoc> What I think we might know: the userspace:kernel time-to-send Havoc> ratio should always be around 2:1, if both of them are Havoc> similarly-implemented, because the userspace version has about Havoc> 2x the work to do. I'm not sure I agree with this statement, just putting something into the kernel doesn't magically make the work go away, and the overhead people are talking about won't change if applications and libraries keep opening/closing the connection to the bus all the time. Havoc> The actual wall-clock time of course depends on the hardware Havoc> and what's being sent. Havoc> If there was a deviation from 2:1 in a benchmark, it might be Havoc> because of implementation issues - so for example Havoc> libdbus+dbus-daemon might be 3:1 or 5:1 to sd-dbus+kdbus, Havoc> because sd-dbus isn't as bloated as libdbus, say. That isn't Havoc> telling you anything about kernel vs. userspace architecture, Havoc> the extra ratio above 2:1 is only telling you about userspace Havoc> implementation quality. Which is also telling you that maybe userspace could be improved more, before it needs to even think about going into the kernel? Havoc> For purposes of deciding what to put in kernel - the Havoc> differences between dbus client implementations (sd-dbus, Havoc> libdbus, gdbus, etc.) seem like irrelevant noise to me. Havoc> Re: the slippery slope to LDAP in the kernel - my questions Havoc> would be things like 1) what are non-performance reasons to Havoc> have dbus in the kernel, such as early boot or security Havoc> considerations; 2) does LDAP in kernel give these kind of 2:1 Havoc> gains; 3) is there a simpler way to get the 2:1 gain for Havoc> dbus... Havoc> Others can answer those better than I can. Havoc> I _would_ say that dbus is more "generic" than something like Havoc> LDAP; dbus is specific to the use-case of coordinating Havoc> processes on a single machine, but it isn't specific to any Havoc> particular application, and it's been used for lots of Havoc> different applications. On my laptop, which is a pretty normal Havoc> fedora 21 as far as I know: LDAP is pretty damn generic, in that you can put pretty large objects into it, and pretty large OUs, etc. So why would it be a candidate for going into the kernel? And why is kdbus so important in the kernel as well? People have talked about it needing to be there for bootup, but isn't that why we ripped out RAID detection and such from the kernel and built initramfs, so that there's LESS in the kernel, and more in an early userspace? Same idea with dbus in my opinion. Havoc> $ rpm -q --whatrequires 'libdbus-1.so.3()(64bit)' | wc -l Havoc> 113 Havoc> 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, Havoc> This particular argument doesn't resonate with me ... if dbus Havoc> is hard to debug, it's not as if "ad hoc application-specific Havoc> sidechannel somebody cooked up" is going to be easier. When Ted is saying it's hard to debug... then maybe it's a bit crappy in design or implementation? Havoc> People aren't usually making up data to send around just because they Havoc> can. If they need to send an audio stream, and dbus is too slow, Havoc> they'll send it another ad hoc way, but it ultimately has to get sent. Havoc> Same for most data, it is the size it is and it needs to go where it Havoc> needs to go, for some what-the-user-wants-to-do kind of reason. Havoc> If apps have to, they say "I'm sorry Dave I can't do that - you Havoc> can't software-decode 4K video on your 300mhz ARM" - of course. So why DOES audio need to go via DBUS? What about video? Why shouldn't that go via dbus as well? If one userspace implementation is so crappy, why can't that implementation be tossed and a better one done? Or why can't they just optimize/tune it in userspace instead? John -- 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/