D-Bus optimizations

[Bart Cerneels]

On wo 14 mrt 2012 02:01:43 CET, Havoc Pennington wrote:
> 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

Context switches is the biggest single problem to be solved since it 
causes priority inversions. The anecdotal case was just to point out 
the underlying architectural problem causes very real bugs. Don't think 
it's the only project stumbling on this, just the best understood.

Here is some supporting material:
http://shorestreet.com/sites/shorestreet.com/files/dbus-perf-report-0.9.9.pdf
Notice the heavy emphasis on priority and scheduling.

Bart