bart.cerneels at collabora.co.uk
Wed Apr 18 04:06:36 PDT 2012
On 18-04-12 12:26, Thiago Macieira wrote:
> On quarta-feira, 18 de abril de 2012 08.13.11, Bart Cerneels wrote:
>>> I'd like to bring it to some kernel developers to have their feedback, but
>>> I don't want to waste their time if we can poke holes with the D-Bus side
>>> of it.
>> To me it sounds like we want to solve a priority inversion problem by
>> deliberately raising priority.
> Do you know of any other ways of solving a priority inversion problem?
In this case you just have to limit the effect size of the problem. You
can still have priority inversion between 2 D-Bus peers communication
heavily. But at least it will not affect all the bus participants if
there is no single central serialized access channel in the daemon.
>> Clever scheduler tricks can certainly help, but don't solve the
>> fundamental problem of the daemon being the bottleneck.
> The broadcasting via the kernel is a good solution, but unlike the daemon, the
> kernel cannot use limitless memory. It has to block on receiving data from the
> userland at some time. Therefore, the kernel solution swaps one problem for
It even is a problem in userspace when the used memory balloons out of
control. I think a solution to this will also fix the problem in the kernel.
How about a much smaller (like 4K/ 1 page size) limit to message size
and handling larger messages transparently using ex. fd passing?
More information about the dbus