D-Bus optimizations
Havoc Pennington
hp at pobox.com
Tue Mar 13 18:01:43 PDT 2012
On Tue, Mar 13, 2012 at 11:41 AM, Colin Walters <walters at verbum.org> wrote:
> What I'm getting out of this is basically "here's a list of other
> ideas". We need to focus though on evaluating the tradeoffs.
Also there's still a need to define the _problem_ surely ...
Right now it feels like there's an anecdote about missing incoming
calls on a pretty old piece of Nokia hardware ... and even for that,
we don't have a (public, anyway) analysis of which processes were
involved and what messages they were sending. We can't answer
questions like "were the apps doing something ridiculous or something
reasonable?" - I mean, it's just unknown.
- how would one objectively determine whether a particular patch
solves the problem this thread is about? where the problem should be
something user-visible, ideally.
- how would one analyze the problem - say, profiling it or
instrumenting it to understand what's happening?
Surely some kind of repeatable test case is needed.
I don't doubt that at some point someone did an analysis and correctly
figured out that reducing context switches would have been really
helpful. But if you're now stepping back and saying what _else_ would
be helpful, or asking if there are ways to reduce context switches
other than bypassing the daemon (such as batching up writes or using a
sidechannel), etc., one sort of needs that test case back to be
re-analyzed.
Havoc
More information about the dbus
mailing list