Comment 22 for bug 188226

Is it possible to disable the group scheduler completely (both
FAIR_CGROUP and FAIR_USER off)?

Otherwise I really suspect the current config is going to cause varied
minor but widespread issues. Your printer requires a software
rasterizer? The desktop will get laggy when you print. Copying some
big files to another machine via nautilus sftp://? The sshd process
will start hurting interactivity. Nicing doesn't help either of those
cases. Try using /sys/kernel/uids/*/cpu_share instead? (and do we
really expect users to figure that out?) Oops, now xorg doesn't get
enough processor time to keep the gui running smoothly, but only if
you're using certain video chipsets that have Xorg drivers that don't
off-load certain tasks to the videocard. All issues I've run into
since updating to hardy (after using cfs and ck's sd and staircase
schedulers for years alongside stock ubuntu and mainline kernels,
without any of these issues). :)

Nicing apt and updatedb no
longer does the obvious thing, while cpu_share ends up being far too
broad: either apps get choppy because they can't run, or they get
choppy because Xorg can't run.

Don't get me wrong, I _very_ happy that we're finally running a cfs
kernel by default, but I'd be surprised if I've exhaustively
enumerated all the interactions caused by what seems to be an
afterthought.

I can't think of any workload other than a server where a simple uid
based approach would be close to the right thing, and yet here we are,
with the server install being the only x86 kernel with the ability to
do anything but the uid approach, and the known regressions in the
generic kernel not being fixed because of non-specific concerns of
regressions, caused by, what, reverting to the old behaviour?