[systemd-devel] Designing a scheduler interface

[Lennart Poettering]

On Thu, 13.01.11 18:29, Daniel Poelzleithner (poelzi at poelzi.org) wrote:

> Hi,
> 
> I'm currently implementing a dynamic linux kernel optimizer called
> ulatencyd [1]. In my opinion the desktop experience (which applies to
> servers as well) can be much improved by dynamically adjusting the the
> kernel. Having a very fair scheduler is a very good thing, but this is
> not the best experience for a user. The user for example expects the
> current used program to be as fast as possible, not some random
> background task getting the same cpu usage. To accomplish this I
> implemented a userspace daemon that analyses the system, and dynamically
> adjusts parameters of the kernel. Currently this is mostly done with
> cgroups, but interfaces to other parameters like ionice etc already exist.
> 
> Many parameters can already be detected by looking at system stats like
> free memory, swapout usage and the process parameters like rss, session,...
> 
> 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.
> 
> 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.

My rough plan is to introduce systemd sooner or later as session manager
into GNOME and then come to a new definition of what an app is along the
lines of "one cgroup per app, matching one .desktop file". That
information would then be available to things like gnome-shell to match
processes to apps to desktop files to windows, instead of the current
heuristics everybody uses. The goal in the long run is definitely to
give the foreground app an extra CPU boost, where gnome-shell decides
what the foreground app is.

Note that systemd currently by default creates a cgroup for each system
service in the cpu hierarchy to give every service the same amount of
CPU. For a while we were also giving each login session the same, to
ensure that every user who is logged in gets an equal amount of CPU,
however we disabled that again since unfortunately the cpu cgroup
controller makes it impossible to use RT sched in a sane way then, right
now. We need to fix the kernel first before we can reenable this.

However at this point in time it's much to early to talk about all of
this. We are slowly working in this direction, but it's not on the table
for the next half year, and we first need to finish introduction of
systemd for the system before thinking about the session.

I see litle value in introducing a dbus interface for any of this. I
would like to see information like this attached to the process and the
cgroup itself without going throught the indirection of an additional
asynchronous messaging layer. My not-so-secret plan to making this
possible is via xattr support in procfs and cgroupfs.

Anyway, as mentioned, I am not really ready to discuss this now. Sorry
of that might sound disappointing.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.