control groups

[Bart Cerneels]

On di 17 apr 2012 22:02:20 CEST, Thiago Macieira wrote:
> Any reactions to the proposal below?
>
> 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.
Clever scheduler tricks can certainly help, but don't solve the 
fundamental problem of the daemon being the bottleneck.

>
> On sexta-feira, 13 de abril de 2012 16.55.26, Thiago Macieira wrote:
>> So I think that this is a nice exercise to get the brain started, but we'll
>> need kernel help. I'd suggest instead:
>>
>>   - a new system call that returns a priority-inheritance file descriptor
>>
>>   - said FD is passed in the D-Bus message
>>
>>   - whenever a thread is polling that FD, its priority is automatically
>> inherited by a process holding that FD open -- this includes FDs currently
>> queued in a Unix socket buffer
>>
>>   - if a process has multiple priority FDs open, it gets the highest priority
>> among them
>>
>> This solves the problems above:
>>   a) the priority is given by poll / select, so there's no race condition
>>
>>   b) since the priority is received automatically, there's no priority
>> inversion: you have the FD open, you get it
>>
>>   c) since we're giving the priority by way of the very syscall we use to
>> find out if there's more data on the socket, the sender can be woken up by
>> socket data and process it (except if you've given an RT FIFO priority
>> away).
>>
>>   d) since the priority is given when the calling thread goes to sleep, by
>> consequence it's not running; if it does wake up, the given priority is
>> taken away
>>
>> Additional benefits:
>>   e) if the call timed out, the calling thread resumes execution and takes
>> away its priority
>>
>>   f) the daemon code and the library actually need no modification to receive
>> priorities: since they receive all file descriptors and keep them open for
>> the duration of the DBusMessage, they have the priority.
>>
>>    However, the daemon code should be modified so it does *not* forward the
>> priority FD to eavesdropping receivers. In fact, it should *only* forward to
>> the intended receiver, which also neatly solves the issue of priority FDs
>> being passed in signal messages: the bus gets the priority, but doesn't
>> pass it along
>>
>>   g) user code often keeps the original DBusMessage around before sending its
>> reply, if nothing else for the serial ID. Code that drops the message
>> should be adapted to keep it around or at least keep the priority FD. The
>> priority FD should be sent along the reply, so the bus daemon gets the
>> priority needed to process it.
>>
>>   h) since a thread gets the highest priority from the priority FDs it has
>> open, the bus daemon is automatically running at the highest priority of its
>> pending messages, and so are target processes
>>
>> Problem:
>>   priority is usually given per thread, but a file description is a process
>> thing. Which thread gets the enhanced priority? All of them?
>>
>> What do you think?
>>
>>
>> _______________________________________________
>> dbus mailing list
>> dbus at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dbus