control groups

Thiago Macieira thiago at
Wed Apr 18 04:22:18 PDT 2012

On quarta-feira, 18 de abril de 2012 13.06.36, Bart Cerneels wrote:
> > 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.

In other words, not solving the problem.

I'd like to get some feedback on the solution I proposed then, or see if 
anyone has alternative solutions.

> 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?

That's something between D-Bus 2.0 wire format or an extremely different 
transport protocol.

And it doesn't solve the problem of a client sending messages more quickly 
than the receiver reads them. It will just take longer for the memory 
ballooning to go out of control.

Thiago Macieira - thiago (AT) - thiago (AT)
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the dbus mailing list