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) -- Kernel should use CONFIG_FAIR_CGROUP_SCHED https://bugs.launchpad.net/bugs/188226 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
