Last modified: Sat Feb 4 22:44:54 EST 2012
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.
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 won'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.
After installing alsa-plugins-1.0.25 and putting
defaults.pcm.rate_converter "samplerate_best" in ~/.asoundrc,
aplay now uses 45% of the CPU to resample a 44.1 kHz wav file for the
benefit of the 48 kHz AC97 sound device.
After removing the Alsa resampling bypass from xine-lib, xine now uses 80% to 90% of the CPU to do the same thing.
Granted, I need to either step down the resampling to "medium" or get a real sound card, but I'm curious why xine is using roughly double the CPU of aplay for the same task. xine is delivering 2 channels of 16-bit samples, just like aplay.