Is there a way to really prioritize processes or make Linux respect their priorities?

Question

I know there are process priorities like in other operating systems, going from -20 (most prio) to 19 (less prio) but Linux seems to ignore them.

Right now I was building the kernel in the background (although make processes have priority 0) and since it took quite some time I decided to watch something. So I opened a pretty demanding H264 video (~30% of CPU time of a Core2 2.6GHz) in VLC only to find out there was tearing, frames lost, visual artifacts (resulting from the previous I presume), although audio seemed to be fine.

So I decided to change the priority of VLC using renice, concretely seeing that PulseAudio had -11 I decided to put it on par so I did sudo renice -11 -p VLC_PROC_#.

Same thing kept happening, so I went on and set it to -20 but I still kept seeing visual artifacts.

So I wonder, why Linux didn't actually prioritize a -20 process over some 0 processes and give it anything it needed? Is there any way to really prioritize processes in Linux?

In case it matters, I'm running a 64-bit Arch here, XFCE as desktop environment.

EDIT: The kernel compilation was performed in /tmp which I have as tmpfs so its sources and all were already in RAM. RAM usage didn't even reach 60% and there was no paging operations in place.

The scenario detailed above is just a test case, I'm more interested in why Linux performed how it did and if there's any way to get real priorities.

Answer 1

renice does affect the priority of a process. But as you've experienced, just because a process has higher priority doesn't imply that it will have all the resources it needs. A higher priority merely gives the process a bigger chance to grab resources.

renice only affects CPU time. So it only has an effect if two or more processes are competing for CPU time. If the limiting factor is not CPU time but I/O bandwidth, the nice value has no impact. Maybe in your case the compilation is using a lot of disk bandwidth and vlc isn't able to read the data fast enough from the disk. Try ionice instead or in addition to nice.

If you do this often, you'll get better results if the video and the compilation are on separate disks. Also, you may get better results if you preload the video into the disk cache (cat /path/to/video.file >/dev/null, or tail -c +456m | head -c 123m /path/to/video.file >/dev/null to read 123MB starting at offset 456MB) — but unless you have a lot of RAM the compilation is likely to claim the cache space back. If you want to be sure to have the video in memory, make a ramdisk and copy the video to it.

Answer 2

Process priority is not the only thing that comes into play when you are trying to tweak user experience. Compiling the kernel is a rather I/O-heavy thing - lots of reading/writing from/to small files which can stretch the file system quite a bit (there is a reason why it is sometimes used as a benchmark in its own right), especially on a multiprocessor machine. If you have enough RAM, I suggest you try to compile the kernel in tmpfs - at least partly: either put source tree there (which will effectively act as prefetching it into the cache) or send the output there by using

make O=/dev/shm ...

or wherever you decide to mount your tmpfs instance big enough to hold the kernel object files - which can easily be in the gigabyte range).

Apart from that you can also check whether VLC has a caching feature (my guess is it has, for example for MPlayer has the -cache option) with which you can request caching the data internally. Then it doesn't need to get the data as it needs them but when they become available.

Another thing is that the displaying is done through the X server - its priority would have to be boosted as well (see Wumpus Q. Wumbley's comment under the question).

Two more options are using cgroups and/or RT scheduler (for the first on see e.g. controlling priority of applications using cgroups, for the latter see e.g. the Gentoo instructions).

The last thing is, that you might want to optimize your system a bit, by turning of unnecessary services. Personally I would consider PulseAudio being the one to start with.

However what you describe sounds more like some high priority I/O happening - my guess is, you experienced some heavy swapping - are you sure your tmpfs wasn't forced to be swapped out? In that case I'm afraid at least iorenice isn't going to be of much help.

Answer 3

As others have said there are many parts of a system that can be affected including the memory bandwidth, and these other parts of the system will also have their own scheduling and priorities.

You could always use chrt -i 0 to give the compilation true idle priority. http://linux.die.net/man/1/chrt

Or throttle the compilation using cgroups. http://kennystechtalk.blogspot.co.uk/2015/04/throttling-cpu-usage-with-linux-cgroups.html

Or throw everything at it:

eatmydata cgexec -g cpu:throttled chrt -i 0 ionice -c3 nice -n19 /path/to/compile-script >/dev/null

Note: nice -n19 shouldn't make any difference if chrt -i 0 is used, but it also won't hurt anything.

My ancient P4 can do the same thing without VLC getting upset.