control groups

[Bart Cerneels]

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
> another.
>

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?

Bart