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
BUT NOT
[ ] 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
fi
# 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
done
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.
<Jedi wave> It does not matter...
...darn.
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.