On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o <ty...@mit.edu> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
