On Thu, 13.01.11 18:29, Daniel Poelzleithner (poe...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel