max_outgoing_bytes: What if a D-Bus peer is too slow to read?

[Colin Walters]

On Fri, Oct 8, 2010 at 9:38 AM, Havoc Pennington <hp at pobox.com> wrote:
> Hi,
>
> Stepping back for a minute, I bet for this kernel thing to work it
> needs to be radically simplified in some way. All the discussions so
> far seem to be going in a direction where there'd be hugely divergent
> code (and even semantics).

Well, one thing we have discovered is that the current semantics of
the bus daemon are pretty unfortunate, specifically the random
arbitrary limits (127MiB and 1GB respectively for the system and
session bus).

> It's just too complex to get right. We
> should also remember that there is not in fact (afaik) a performance
> problem to solve, on desktop hardware;

Actually, I have gotten complaints from people using dbus on even
server-class hardware.  The primary complaint was about latency when
the OS was virtualized (I'm guessing where kvm was configured with 1
virtual CPU).  I didn't debug it, but my guess is that that kind of
situation is going to magnify greatly the scheduling latency,
especially if there's contention for the physical cores.

It probably doesn't help that I think RHEL5 shipped with a version of
dbus-glib which watched all NameOwnerChanged signals, causing
dbus-daemon to write to a ton of different proceses.

> To be more constructive, maybe the way to go is to come up with one or
> two of the most common simple cases, and see if direct delivery is
> possible in those cases.

It seems to me that direct delivery of method calls (without
dbus-monitor) would be the obvious first step.

> Trying to reproduce/replicate dbus-daemon semantics... especially with
> no detailed spec or test suite...

This is part of the point of the discussion, we're debating whether
the dbus-daemon semantics are useful and/or right.  If it makes things
easier for the kernel implementation, and nothing relies on them, we
could look at changing them.