Am 30.12.2017 um 23:06 schrieb dick balaska:
> This is more of a general Linux issue I guess.
> I run povray at nice -19. It doesn't behave as expected. That is, it
> doesn't really yield to other processes.
> When I run povray at low priority on Windows, he basically stops for
> anything else. Like here, povray should be stopped, and ffmpeg given
> 800% of CPU.
Technically, no, that's not what should happen.
What should happen is that ffmpeg should be given (virtially) as much
CPU time _as it can use_. Which may be significantly less than 800% if...
- it spends a lot of time waiting for file I/O to complete (which I
guess may be quite significant when creating a movie);
- it spends a lot of time synchronizing its threads.
- it uses a limited number of threads as there are (virtual) cores;
- it lets the GPU do most of the work, rather than the CPU;
CPU power ffmpeg makes no use of for any of the above reasons is free
for the taking.
(Also, with a niceness of 19 rather than the maximum of 20, the
scheduler would still give POV-Ray a bit of CPU time even if ffmpeg
would be able to use it all up.)
> PID USER PR NI VIRT SHR S %CPU %MEM TIME+ COMMAND
> 8976 dick 39 19 1301940 4512 S 539.4 2.6 32:43.18 povray
> 11804 dick 20 0 3873964 31452 S 194.4 1.1 5:25.79 ffmpeg
> This can't be just the way things are?
Judging from the numbers, my guess would be that ffmpeg only uses 2
worker threads (giving it a theoretical maximum of 200%), each of which
occasionally blocks due to file I/O or synchronization (dropping the
actual value to 194%).
The internerds make various contradicting claims about the number of
threads used by ffmpeg, some of which coincide with the value you get.
The internerds also claim that using ffmpeg's `-threads N` option should
Post a reply to this message