control groups

[Havoc Pennington]

Hi,

On Fri, Apr 13, 2012 at 3:08 PM, Robin Bate Boerop <me at robinbb.com> wrote:
> D-Bus is fundamentally broken performance-wise in the way described in the paper.

I don't agree with you here, maybe that's clear. For me the question
is: what is the user-visible impact? And in most cases (on the desktop
at least), it has been zero. I don't agree with saying "fundamentally
broken" when something is widely-adopted and solving real problems.

Now yes, there are cases where it doesn't work and it could, but "it
could be useful in more situations than the original design target"
and "fundamentally broken" are VERY different statements.

I'm not just trying to nitpick language.

If you are thinking "fundamentally broken" then any measure is
worthwhile even if it breaks other stuff and takes a lot of community
effort. So that's why I don't think "fundamentally broken" is the
right way to frame it.

The right way to frame it is _tradeoffs_. The performance issue here
was known on _day one_ when implementing dbus, and deemed worth the
tradeoff; which isn't to say it can't be improved, but in some sense
the performance issue was "the point" (because the central daemon
brought other advantages, both conceptual and practical). I think the
value of that choice has been apparent in that dbus has been widely
adopted and solved a whole lot of problems on the Linux desktop, and
that dbus _exists_. If there were no tradeoff, then we might have a
solution that was best of all worlds by now, and we do not.

Conceptually such a best-of-all-worlds solution could exist (at least
if you can change the kernel, though that won't help on Windows
either), and it's great to work on it, but don't assume there's no
baby in the bathwater.

In terms of user-visible impact, it sure sounds like there are
potentially significant, low-hanging performance gains on both desktop
and mobile Linux devices, whether it's messing with scheduler config
or some of the dbus changes we discussed in the earlier thread. That's
why I keep lobbying this point: it sure seems like someone should take
a crack at some of these, even if they are not "fundamental" they are
still real.

You can say it's fundamentally broken _for some purpose_ and that's
fine. But I would strongly argue that it is not broken for the actual
original intended use (= most but not all Linux desktop IPC scenarios)
and I also suspect that it can be made to work well for mobile Linux
devices with relatively incremental improvements to dbus and/or apps.

Havoc