Use of CPU bandwidth provisioning feature (single-core)

Last modified: Sun Jun 2 10:51:26 EDT 2019


This information is old.  For the problem described below, the SCHED_DEADLINE option that was added in Linux kernel version 3.14 probably offers a better solution.

Linux 3.2.2 mainline

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 4745 dave      -2   0  206m  45m 9848 S   86  1.5   9:32.52 xine

The challenge was to get this nigh-overloaded xine process to be immune to stuttering when other jobs compete with it on an old single-core PC.  Preemptible Kernel (Low-Latency Desktop) and realtime priority for xine were not enough.  <Jedi wave> It does not matter why xine is using so much CPU. </Jedi wave>

The Control Group CPU bandwidth provisioning feature seems to be more effective for guaranteeing realtime processes their share of cycles, but it really kills the performance of everything that gets throttled.

Kernel options to enable:

[*] Control Group support  --->
  [*]   Group CPU scheduler  --->
    [*]   Group scheduling for SCHED_OTHER
    [*]     CPU bandwidth provisioning for FAIR_GROUP_SCHED


[ ] Automatic process group scheduling

(The latter is designed to ensure desktop responsiveness in the face of CPU-heavy jobs, which is the opposite of what's needed here.)

The following Bash function, executed with root privileges after xine is started, moves all non-root processes except for xine into a group that is limited to 20% of the CPU:

function fixxine {
  if [ ! -d /sys/fs/cgroup/slow ]; then
    mkdir /sys/fs/cgroup/slow
  # Piping the list into /sys/fs/cgroup/slow/tasks doesn't work
  for f in `ps --no-headers -N -U root -C xine -o pid`; do
    echo $f > /sys/fs/cgroup/slow/tasks
  echo $((`< /sys/fs/cgroup/slow/cpu.cfs_period_us` / 5)) > /sys/fs/cgroup/slow/cpu.cfs_quota_us

Having done that, xine is good with Firefox and xine is good with compile jobs, but with both going at the same time, there are occasional dropouts.  Nevertheless, the dropouts are occasional enough and the slowdown to Firefox is horrendous enough already that I wouldn't mess with it further.

xine also has dropouts when I move significant amounts of file data, but in that case, neither the I/O lag nor the work being done by root/kernelspace for encryption are in scope of the CFS quota.

As of kernel version 3.7, an analogous bandwidth provisioning feature for I/O bandwidth is available (Block IO controller under Control Group support, CFQ Group Scheduling support under IO Schedulers → CFQ I/O scheduler) that would likely fix the remaining problem.  Together with automatic process group scheduling, it works wonders for a netbook that is bottlenecked by a slow SSD.

So why is xine using 80% CPU?

<Jedi wave> It does not matter...


OK, well, after installing alsa-plugins-1.0.25 and putting defaults.pcm.rate_converter "samplerate_best" in ~/.asoundrc, xine used 80% to 90% of the CPU to resample a 44.1 kHz wav file for the benefit of the 48 kHz AC97 sound device.  aplay used only half that much CPU, and I never figured out why there was such a difference between the two.

Regardless, it wasn't a sustainable configuration.  "speexrate_best" is supposedly equivalent to "samplerate_best", but uses much less CPU, so I switched to that while shopping for a PCI sound card that doesn't suck.