Comment 3 for bug 188226

As far as I understand it, CONFIG_FAIR_CGROUP_SCHED is still the preferred configuration and will provide the previous behavior by default (with only one big group for all processes). However, setup seems to be more difficult/powerful (see Documentation/cgroups.txt in the linux source).

I don't know, if it matches the requirements for Ubuntu, but you can easily create the same behavior as with CONFIG_FAIR_USER_SCHED: just create a cgroup per user, listen to the uevent "add /kernel/uids/" in udev and then put any future processes into this cgroup, where then also child processes will go.

This way, C_F_USER_SCHED could be simulated and has the better default on a desktop system.

Using the uevent interface to dynamically adjust the cpu_share (for USER_SCHED) or cpu.shares (for CGROUP_SCHED) of users (upon creation of /sys/kernel/uids/USERID) based on a configuration directory would allow to tune it.

E.g., the boinc package would install a file in /etc/cgroups-conf.d/boinc with:
user==boinc cpu_share=2
to assign the lowest possible value of cpu shares to the boinc user.

The package that installs /etc/cgroups-conf.d/ (or similar) would install a udev script to hook into the kernel uevent process. This script then would check if the added user in /sys/kernel/uids/ is listed in one of the config files and adjust the cpu.shares accordingly. (another selectors could be "group", e.g. "group=www-data").

This way, packages can provide default cpu_share values for a given user and the admin can easily adjust them.

Does it make sense to switch to using CGROUPS and provide a userland configuration package for it?

(I've not tested the two mentioned sched patches yet in the new kernel in Ubuntu)