Designing a scheduler interface

[Scott James Remnant]

Hi Daniel,

Thanks for getting in touch.

On Thu, Jan 13, 2011 at 5:29 PM, Daniel Poelzleithner <poelzi at poelzi.org> wrote:

> What is currently unknown on the other hand is the current active X
> window in use. This could be done by connecting tho X and reacting to
> events there, but I think a cleaner approach would be that the window
> manager signals the running optimisation daemon that a given program is
> of user importance. May it be that the program has focus or is visible
> on the screen. I would like to have a standard dbus interface for this.
>
Would ConsoleKit not know which is the currently active session on a given seat?

> Another problem I expect are clashes between systems that try to control
> similar kernel subsystems. systemd at least uses cgroups in some parts.
> We need to define some interface between init and the scheduling daemon
> if one is running. Elsewise some expected behaviour won't work. When
> init signals the optimizer the importance of services, this could be
> taken into account for the decision he makes.
>
A cgroup hierarchy is associated with particular subsystems, and you
can have many cgroup hierarchies.  As long as the init daemon is not
using the same subsystem as you, you can simply control it using an
entirely separate hierarchy, though it would be up to you to move
tasks into and out of your own.

If there were overlap, some care would be required, because the init
daemon may be using the cgroup for supervision purposes - removing a
task from the group could mean the init daemon believes the service is
no longer running.  One obvious solution here is to move tasks into
sub-groups with differing parameters and expect the init daemon to
clean up when empty (as it's in its own hierarchy).

Assuming the above, I don't see any real need for a complex
interaction between them - the interface is the existing kernel
interfaces.

Unless I've wildly missed the point ;-)

Scott