Re: [GIT PULL] kdbus for 4.1-rc1

["John Stoffel" <john@stoffel.org>]

>>>>> "Havoc" == Havoc Pennington <hp@pobox.com> writes:

Havoc> On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o <tytso@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.
>> 

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