Cdtjkyj

I've been using x265 to encode some video on my workstation lately, but I have a problem: even though I launch it using nice -n 20 x265 to deprioritize it, it still slows the computer to a crawl while it's running. Everything still works, it's just... slow! I even see delays before the characters appear while typing in a terminal.

Do I have to live with this, or are there some other things I can try?

EDIT: Perhaps the following serves as proof that the nice value really is getting applied to x265? Look at the NI column.

% ps -awux -O nice | egrep "x265|PID"

USER      PID  %CPU %MEM     VSZ     RSS TT  STAT STARTED       TIME COMMAND            PID NI TT  STAT       TIME COMMAND

nobody  56654 789.3  3.7  785656  623384 11  SN+J 11:56PM    6:05.80 x265 --input-csp 56654 20 11  SN+J    6:05.80 x265 --input-csp i420 --bframes 5 -

Sometimes a single heavy I/O operation may affect kernel performance with respect to all I/O taks, including those not directly operating on the device of the first one.

• The first and indirect way to control priorities on I/O scheduling is the tuning of process' nice level you already mentioned. In modern Linuxes, a process with a nice value of 19 (i.e., the maximum) is by default in the best effort class with priority equals to (19 + 20) / 5 = 7, which is the lowest priority available within the class. More generally, it ranges in [0,7] according such a mapping function.




• A second, direct and more powerful way to control I/O scheduling is to manually intervene on the I/O scheduling class assigned to processes. This allow us to put a process also in two additional classes:
  real-time class, with higher priority than best effort level 0, and
  idle class, with lower priority than best effort level 7. This last theoretically guarantees that no other I/O operation could ever wait for a idle-scheduled process operation.
  Similarly to the nice command, the ionice allows one to spawn a process with a given priority or to change priorities of an existing process. More information about this tool and I/O scheduling on Linux kernels in general may be found in ionice man page.

That being said, have you tried to launch your process with ionice -c 3 x265 ...?

P.S. Sorry, I noticed the 'FreeBSD' tag in the question after posting my answer, which perhaps collapses into the following.

I don't think FreeBSD has any I/O scheduler. You may consider perform your work on a Linux box, which has it and it is quite is easy to play with it.

The FreeBSD kernel does implement something like an I/O scheduler, namely gsched. Reviewing the manual page, it seems to be a device-specific IO scheduler. Personally, I think it's a nice keynote toward realtime applications of FreeBSD, and a great reason to search for the existing FreeBSD documentation, candidly.

Albeit speculatively, perhaps with the root partition's block device configured to use an rr scheduler, using gsched, and the media files stored on a separate block device, perhaps it might serve to allow for the operating system to function more responsively, in I/O, even with the I/O bottleneck?

Perhaps, with gsched applied along with a configuration for processor priorities -- applying such as rtprio and/or idprio -- it might serve to improve the responsiveness of the primary operating system, even under heavy load from the media file processing.

Alternately, perhaps it might be possible to gain some more processor bandwidth, with ports compiled under CPU-specific optimizations. Towards that effect, there are the MACHINE_CPUARCH and CPUTYPE fields, such that may be applied in /etc/make.conf, and that would be applied during the ports build process [manual page]. The Handbook, of course, provides a lot of pointers about building ports with FreeBSD [ch.5]. Myself, I've been using MACHINE_CPUARCH?=amd64 and CPUTYPE?=core2 on an older Toshiba laptop. It seems to work out OK as a LAN gateway, though albeit I've not benchmarked it under high load in the processor or block I/O features.

You want "rctl"

see:

man rctl

which lets you allocate resources per user, per process, jail or login class. E.G.

# user root, maximum reads of 400 transfers per sec (tps) per the whole user :

rctl -a user:root:readiops:throttle=400/user



# user root, maximum reads of 30Mb per sec (31,457,280 bytes) per the whole user :

rctl -a user:root:readbps:throttle=31457280/user