Why does the ‘user’ and ‘sys’ time vary on multiple executions

processschedulingtime

There is a nice question and answer explaining the relationships between 'real', 'user' and 'sys'.

It explains the reasons why 'real' can vary, and defines the 'user' and 'sys' as times the process actually spent running on the processor.

Let's now completely ignore 'real'. I have noticed that when running the same application multiple times, it gives different 'sys' and 'user'.

$time dummy_app
user    0m0.032s
sys     0m0.064s

$time dummy_app
user    0m0.020s
sys     0m0.084s

The dummy_app is just a for loop that counts from 0-100000.

What is the reason that the execution of the same binary would spend different times on the processor? In other words, why aren't 'user' and 'sys' always the same for the same app?

Best Answer

Why execution times of the same binary differ on multiple executions

The key problem here is the non-deterministic behavior due to the way the CPU works. Modern superscalar CPUs can execute multiple instructions at a time or change the order of commands to be executed (out-of-order execution). Regarding your example, it's also possible that optimization in cache use applies. RAM is several magnitudes slower than the CPU itself, that's why intensive caching is used. The second run of your binary might run in the cache, thus consuming less CPU cycles (cycles the CPU would have waited for the data to be retrieved from memory).

On the difference of real, user and sys process time statistics

One of these things is not like the other. Real refers to actual elapsed time; User and Sys refer to CPU time used only by the process.

  • Real is wall clock time - time from start to finish of the call. This is all elapsed time including time slices used by other processes and time the process spends blocked (for example if it is waiting for I/O to complete).

  • User is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process. Other processes and time the process spends blocked do not count towards this figure.

  • Sys is the amount of CPU time spent in the kernel within the process. This means executing CPU time spent in system calls within the kernel, as opposed to library code, which is still running in user-space. Like 'user', this is only CPU time used by the process. See below for a brief description of kernel mode (also known as 'supervisor' mode) and the system call mechanism.

User+Sys will tell you how much actual CPU time your process used. Note that this is across all CPUs, so if the process has multiple threads it could potentially exceed the wall clock time reported by Real. Note that in the output these figures include the User and Sys time of all child processes (and their descendants) as well when they could have been collected, e.g. by wait(2) or waitpid(2), although the underlying system calls return the statistics for the process and its children separately.

Source