Re: kdbus: to merge or not to merge?

[Andy Lutomirski]

On Aug 6, 2015 1:04 AM, "David Herrmann" <dh.herrmann@xxxxxxxxx> wrote:
> >          Given that all existing prototype userspace that I'm aware of
> > (systemd and its consumers) apparently opts in, I don't really care
> > that the feature is opt-in.
>
> This is just plain wrong. Out of the dozens of dbus applications, you
> found like 9 which are buggy? Two of them are already fixed, the
> maintainers of the other ones notified.
> I'd be interested where you got this notion that "all existing
> prototype userspace [...] opts in".
>

I would say instead that, out of one in-use kdbus library, I found one
that was buggy.  Maybe gdbus really does use kdbus already, but on
very brief inspection it looked like it didn't at least on my test VM.

>
> > Also, you haven't addressed the memory usage issues --
>
> ..because it doesn't change anything. If your IPC is message based and
> async, _someone_ needs to buffer. I don't see the difference between
> buffering locally on !EPOLLOUT or buffering in a shmem pool. In both
> cases, clients have control over the buffer size. If you disagree,
> please _elaborate_.

If the client buffers on !EPOLLOUT and has a monster buffer, then
that's the client's problem.

If every single program has a monster buffer, then it's everyone's
problem, and the size of the problem gets multiplied by the number of
programs.

Also, sensible clients that produce bulk data will throttle on
!EPOLLOUT rather than blindly buffering, but that's not an option when
the huge buffer is on the receiver's end.  Read up on "bufferbloat".

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/